Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > On 18/02/20 15:44, Vitaly Kuznetsov wrote: >> Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> >> --- >> RFC: This is somewhat similar to eVMCS breakage and it is likely possible >> to fix this in KVM. I decided to try QEMU first as this is a single >> control and unlike eVMCS we don't need to keep a list of things to disable. > > I think you should disable "virtual-interrupt delivery" instead (which > in turn requires "process posted interrupts" to be zero). That is the > one that is incompatible with AutoEOI interrupts. I'm fighting the symptoms, not the cause :-) My understanding is that when SynIC is enabled for CPU0 KVM does kvm_vcpu_update_apicv() vmx_refresh_apicv_exec_ctrl() pin_controls_set() for *all* vCPUs (KVM_REQ_APICV_UPDATE). I'm not sure why SECONDARY_EXEC_APIC_REGISTER_VIRT/SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY are not causing problems and only PIN_BASED_POSTED_INTR does as we clear them all (not very important atm). > > The ugly part about fixing this in QEMU is that in theory it would be > still possible to emulate virtual interrupt delivery and posted > interrupts, because they operate on a completely disjoint APIC > configuration than the host's. I'm not sure we want to go there though, > so I'm thinking that again a KVM implementation is better. It > acknowledges that this is just a limitation (workaround for a bug) in KVM. The KVM implementation will differ from what we've done to fix eVMCS. We will either need to keep the controls on (and additionally check kvm_vcpu_apicv_active() if guest tries to enable them) and again filter VMX MSR reads from the guest or do the filtering on MSR write from userspace (filter out the unsupported controls and not fail). Actually, I'm starting to think it would've been easier to just filter all VMX MSRs on KVM_SET_MSRS leaving only the supported controls and not fail the operation. That way we would've fixed both eVMCS and SynIC issues in a consistent way shifting the responsibility towards userspace (document that VMX MSRs are 'special' and enabling certain features may result in changes; if userspace wants to see the actual state it may issue KVM_GET_MSRS any time) May not be the worst solution after all... -- Vitaly
