[PATCH v2 0/8] My AVIC patch queue

[Maxim Levitsky]

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(-)

-- 
2.26.3