Re: [PATCH RFC] target/i386: filter out VMX_PIN_BASED_POSTED_INTR when enabling SynIC

[Vitaly Kuznetsov <vkuznets@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 18/02/20 15:44, Vitaly Kuznetsov wrote:
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>> 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