On 2013-03-12 14:09, Paolo Bonzini wrote: > Il 12/03/2013 13:46, Jan Kiszka ha scritto: >>>>>>>> @@ -6178,7 +6177,13 @@ int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu, >>>>>>>> int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu, >>>>>>>> struct kvm_mp_state *mp_state) >>>>>>>> { >>>>>>>> - vcpu->arch.mp_state = mp_state->mp_state; >>>>>>>> + if (mp_state->mp_state == KVM_MP_STATE_SIPI_RECEIVED) { >>>>>>>> + if (!kvm_vcpu_has_lapic(vcpu)) >>>>>>>> + return -EINVAL; >>>>>>>> + vcpu->arch.mp_state = KVM_MP_STATE_INIT_RECEIVED; >>>>>>>> + set_bit(KVM_APIC_SIPI, &vcpu->arch.apic->pending_events); >>>>>>>> + } else >>>>>>>> + vcpu->arch.mp_state = mp_state->mp_state; >>>>>> >>>>>> Should INIT_RECEIVED also be invalid without an in-kernel LAPIC? >>>> >>>> And since migration was brought up yesterday, do we need an interface to >>>> retrieve and set this? >>>> >>>> And should KVM_GET/SET_VCPU_EVENTS use the new sipi_vector in the APIC >>>> rather than the old one? >> I hope not. The idea is that the APIC events are processed before the >> migration completes. Translating events on get_mpstate should ensure this. > > What about persistent state such as "an INIT has been received and > caused a vmexit, but is being latched until vmxoff"? Perhaps we could > use the top 8 bits of vcpu->arch.sipi_vector for this, they are always > shifted out when sipi_vector is used, and should be zero in all cases. > It would then be possible to reuse KVM_GET/SET_VCPU_EVENTS. See my other mail. > > Migration support for nested VMX is still far far away, so perhaps we do > not care, but we still need a way to inject INIT from userspace. Ack for INIT injection. In theory, you could use the VCPU event IOCTL, it is extensible. If that is elegant is another question. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- 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