Re: [PATCH] x86: kvm: reset the bootstrap processor when it getsan INIT

[Paolo Bonzini]

Il 11/03/2013 12:51, Gleb Natapov ha scritto:
>> > 
>> > Agreed, but we still have the problem of how to signal from userspace.
>> > For that do you have any other suggestion than mp_state?  And if we keep
>> > mp_state to signal from userspace, giving INIT_RECEIVED the
>> > "wait-for-SIPI" semantics would be wrong.
>> > 
> I don't see how can we use mp_state for signaling from userspace either.
> Currently soft reset always reset vcpus, so it is OK for userspace to
> generate reset vcpu state and put it into kernel, mp_state is just one
> of the updated states, but when INIT will be just another signal that
> may or may not reset cpu or have other side effects like #vmexit this
> will not longer work. We will have to have another interface for
> injecting INIT from userspace and userspace soft-reset will use it
> instead of doing reset by itself.

Setting the mp_state to INIT_RECEIVED is that interface, and it already
works, for APs at least.  This patch extends it to work for the BSP as well.

In the corresponding userspace patch, I don't need to touch the CPU
state at all.  I can just signal the kernel.  If I touch the CPU, I'll
break the nested case, no matter how it is implemented.  So far, the
userspace did not have to worry about nested, and that's something that
should be kept that way.

If we move away from the INIT_RECEIVED and SIPI_RECEIVED states for
in-kernel APIC -> VCPU communication, then the KVM_SET_MP_STATE ioctl
will have to convert them to the right bits in the requests field or in
the APIC state.  But I'm starting to see less benefit from moving away
from mp_state.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/