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 kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
