Messages in this thread |  | | Subject | Re: [PATCH v2 0/8] My AVIC patch queue | From | Paolo Bonzini <> | Date | Mon, 26 Jul 2021 19:24:51 +0200 |
| |
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
|  |