lkml.org 
[lkml]   [2021]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 0/8] My AVIC patch queue
From
Date
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

\
 
 \ /
  Last update: 2021-07-26 19:26    [W:0.044 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site