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
