On Mon, Mar 11, 2013 at 12:25:57PM +0100, Paolo Bonzini wrote: > Il 11/03/2013 11:28, Gleb Natapov ha scritto: > >> Not really true---we do exit with that state and EINTR when we get a > >> SIPI. Perhaps that can be changed. > > > > That's implementation detail. We can jump to the beginning of the > > function instead. Nowhere we document that entering > > KVM_MP_STATE_SIPI_RECEIVED state cause KVM_RUN return with EINTR. > > Yes, that would be nice. > That's not performance critical path, so I guess no one bothered. > >>> If AP is hard reset > >>> userspase makes it UNINIT, if soft reset it makes it INIT_RECEIVED, if > >>> BSP it makes it running no matter what type of reset. > >> > >> The current name just suggests . > >> And when getting an INIT in the in-kernel LAPIC, this: > >> > >> - vcpu->arch.mp_state = KVM_MP_STATE_INIT_RECEIVED; > >> + vcpu->arch.mp_state = kvm_vcpu_is_bsp(vcpu) ? > >> + KVM_MP_STATE_SIPI_RECEIVED : > >> + KVM_MP_STATE_INIT_RECEIVED; > >> > >> makes much less sense than this: > >> > >> - vcpu->arch.mp_state = KVM_MP_STATE_WAIT_FOR_SIPI; > >> + vcpu->arch.mp_state = kvm_vcpu_is_bsp(vcpu) ? > >> + KVM_MP_STATE_RESET_NOW : > >> + KVM_MP_STATE_WAIT_FOR_SIPI; > >> > > Both of them are equally incorrect. INIT should cause reset, and only if > > vmx is off. An userspace reset is also completely broken in that regard. > > Renaming things gives us nothing, only bring unneeded churn. If the > > names were internal I wouldn't mind, but they are APIs. > > > >> However, there's also Jan's plans for nVMX. Peeking at his queue (see > >> http://git.kiszka.org/?p=linux-kvm.git;a=commitdiff;h=037fb24ec) I think > >> it's better to always reflect INITs to the hypervisor like I did in these > >> patches. > >> > > The commit was before we decided that we should not abuse mp_state for > > signaling. > > 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. -- Gleb. -- 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
