Sorry in the delay of handling this. Now preparing a bunch of KVM commits to submit. :) > On 11 Sep 2019, at 19:21, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 26/08/19 20:26, Liran Alon wrote: >> An alternative could be to just add a flag to events->flags that modifies >> behaviour to treat events->smi.latched_init as just events->latched_init. >> But I prefer the previous option. > > Why would you even need the flag? I think you only need to move the "if > (lapic_in_kernel(vcpu)) outside, under "if (events->flags & > KVM_VCPUEVENT_VALID_SMM)”. Without an additional flag, the events->smi.latched_init field will be evaluated by kvm_vcpu_ioctl_x86_set_vcpu_events() even when userspace haven’t specified KVM_VCPUEVENT_VALID_SMM. Which in theory should break compatibility to userspace that don’t specify this flag. If you are ok with breaking this compatibility, I will avoid adding an opt-in flag that specifies this field should be evaluated even when KVM_VCPUEVENT_VALID_SMM is not specified. Because we are lucky and “latched_init" was last field in “struct smi” inside “struct kvm_vcpu_events”, I will just move “latched_init” field outside of “struct smi” just before the “reserved” field. Which would keep binary format compatibility while allowing making KVM code more clear. > > In fact, I think it would make sense anyway to clear KVM_APIC_SIPI in > kvm_vcpu_ioctl_x86_set_vcpu_events (i.e. clear apic->pending_events and > then possibly set KVM_APIC_INIT if events->smi.latched_init is true). Agree. Will do this as-well. -Liran > > Paolo
