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. >>> 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. 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
