Re: [PATCH v2 0/8] My AVIC patch queue

[Paolo Bonzini <pbonzini@redhat.com>]

On 13/07/21 16:20, Maxim Levitsky wrote:
> Hi!
> 
> This is a series of bugfixes to the AVIC dynamic inhibition, which was
> made while trying to fix bugs as much as possible, in this area and trying
> to make the AVIC+SYNIC conditional enablement work.
> 
> * Patches 1-4 address an issue of possible
>    mismatch between the AVIC inhibit state and AVIC enable state on all vCPUs.
> 
>    Since AVICs state is changed via a request there is a window during which
>    the states differ which can lead to various warnings and errors.
> 
>    There was an earlier attempt to fix this by changing the AVIC enable state
>    on the current vCPU immediately when the AVIC inhibit request is created,
>    however while this fixes the common case, it actually hides the issue deeper,
>    because on all other vCPUs but current one, the two states can still
>    mismatch till the KVM_REQ_APICV_UPDATE is processed on each of them.
> 
>    My take on this is to fix the places where the mismatch causes the
>    issues instead and then drop the special case of toggling the AVIC right
>    away in kvm_request_apicv_update.
> 
>    V2: I rewrote the commit description for the patch that touches
>      avic inhibition in nested case.
> 
> * Patches 5-6 in this series fix a race condition which can cause
>    a lost write from a guest to APIC when the APIC write races
>    the AVIC un-inhibition, and add a warning to catch this problem
>    if it re-emerges again.
> 
>    V2: I re-implemented this with a mutex in V2.
> 
> * Patch 7 is an  fix yet another issue I found in AVIC inhibit code:
>    Currently avic_vcpu_load/avic_vcpu_put are called on userspace entry/exit
>    from KVM (aka kvm_vcpu_get/kvm_vcpu_put), and these functions update the
>    "is running" bit in the AVIC physical ID remap table and update the
>    target vCPU in iommu code.
> 
>    However both of these functions don't do anything when AVIC is inhibited
>    thus the "is running" bit will be kept enabled during exit to userspace.
>    This shouldn't be a big issue as the caller
>    doesn't use the AVIC when inhibited but still inconsistent and can trigger
>    a warning about this in avic_vcpu_load.
> 
>    To be on the safe side I think it makes sense to call
>    avic_vcpu_put/avic_vcpu_load when inhibiting/uninhibiting the AVIC.
>    This will ensure that the work these functions do is matched.
> 
> * Patch 8 is the patch from Vitaly about allowing AVIC with SYNC
>    as long as the guest doesn’t use the AutoEOI feature. I only slightly
>    changed it to drop the SRCU lock around call to kvm_request_apicv_update
>    and also expose the AutoEOI cpuid bit regardless of AVIC enablement.
> 
>    Despite the fact that this is the last patch in this series, this patch
>    doesn't depend on the other fixes.
> 
> Best regards,
> 	Maxim Levitsky
> 
> Maxim Levitsky (7):
>    KVM: SVM: svm_set_vintr don't warn if AVIC is active but is about to
>      be deactivated
>    KVM: SVM: tweak warning about enabled AVIC on nested entry
>    KVM: SVM: use vmcb01 in svm_refresh_apicv_exec_ctrl
>    KVM: x86: APICv: drop immediate APICv disablement on current vCPU
>    KVM: x86: APICv: fix race in kvm_request_apicv_update on SVM
>    KVM: SVM: add warning for mistmatch between AVIC state and AVIC access
>      page state
>    KVM: SVM: call avic_vcpu_load/avic_vcpu_put when enabling/disabling
>      AVIC
> 
> Vitaly Kuznetsov (1):
>    KVM: x86: hyper-v: Deactivate APICv only when AutoEOI feature is in
>      use
> 
>   arch/x86/include/asm/kvm_host.h |  3 ++
>   arch/x86/kvm/hyperv.c           | 34 ++++++++++++++++----
>   arch/x86/kvm/svm/avic.c         | 45 ++++++++++++++------------
>   arch/x86/kvm/svm/nested.c       |  2 +-
>   arch/x86/kvm/svm/svm.c          | 18 ++++++++---
>   arch/x86/kvm/x86.c              | 57 ++++++++++++++++++---------------
>   include/linux/kvm_host.h        |  1 +
>   virt/kvm/kvm_main.c             |  1 +
>   8 files changed, 103 insertions(+), 58 deletions(-)
> 

Queued patches 1-4, thanks.

Paolo