From: Sean Christopherson <seanjc@google.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] KVM: x86: Fix and cleanup for recent AVIC changes
Date: Mon, 11 Oct 2021 14:27:13 +0000 [thread overview]
Message-ID: <YWRJwZF1toUuyBdC@google.com> (raw)
In-Reply-To: <9e9e91149ab4fa114543b69eaf493f84d2f33ce2.camel@redhat.com>
On Sun, Oct 10, 2021, Maxim Levitsky wrote:
> On Fri, 2021-10-08 at 18:01 -0700, Sean Christopherson wrote:
> > Belated "code review" for Maxim's recent series to rework the AVIC inhibit
> > code. Using the global APICv status in the page fault path is wrong as
> > the correct status is always the vCPU's, since that status is accurate
> > with respect to the time of the page fault. In a similar vein, the code
> > to change the inhibit can be cleaned up since KVM can't rely on ordering
> > between the update and the request for anything except consumers of the
> > request.
> >
> > Sean Christopherson (2):
> > KVM: x86/mmu: Use vCPU's APICv status when handling APIC_ACCESS
> > memslot
> > KVM: x86: Simplify APICv update request logic
> >
> > arch/x86/kvm/mmu/mmu.c | 2 +-
> > arch/x86/kvm/x86.c | 16 +++++++---------
> > 2 files changed, 8 insertions(+), 10 deletions(-)
> >
>
> Are you sure about it? Let me explain how the algorithm works:
>
> - kvm_request_apicv_update:
>
> - take kvm->arch.apicv_update_lock
>
> - if inhibition state doesn't really change (kvm->arch.apicv_inhibit_reasons still zero or non zero)
> - update kvm->arch.apicv_inhibit_reasons
> - release the lock
>
> - raise KVM_REQ_APICV_UPDATE
> * since kvm->arch.apicv_update_lock is taken, all vCPUs will be
> kicked out of guest mode and will be either doing someing in
> the KVM (like page fault) or stuck on trying to process that
> request the important thing is that no vCPU will be able to get
> back to the guest mode.
>
> - update the kvm->arch.apicv_inhibit_reasons
> * since we hold vm->arch.apicv_update_lock vcpus can't see the new value
This assertion is incorrect, kvm_apicv_activated() is not guarded by the lock.
> - update the SPTE that covers the APIC's mmio window:
This won't affect in-flight page faults.
vCPU0 vCPU1
===== =====
Disabled APICv
#NPT Acquire apicv_update_lock
Re-enable APICv
kvm_apicv_activated() == false
incorrectly handle as regular MMIO
zap APIC pages
MMIO cache has bad entry
next prev parent reply other threads:[~2021-10-11 14:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-09 1:01 [PATCH 0/2] KVM: x86: Fix and cleanup for recent AVIC changes Sean Christopherson
2021-10-09 1:01 ` [PATCH 1/2] KVM: x86/mmu: Use vCPU's APICv status when handling APIC_ACCESS memslot Sean Christopherson
2021-10-10 12:47 ` Maxim Levitsky
2021-10-09 1:01 ` [PATCH 2/2] KVM: x86: Simplify APICv update request logic Sean Christopherson
2021-10-10 12:49 ` Maxim Levitsky
2021-10-11 17:55 ` Sean Christopherson
2021-10-10 12:37 ` [PATCH 0/2] KVM: x86: Fix and cleanup for recent AVIC changes Maxim Levitsky
2021-10-11 14:27 ` Sean Christopherson [this message]
2021-10-11 16:58 ` Sean Christopherson
2021-10-12 9:53 ` Maxim Levitsky
2021-10-15 16:15 ` Sean Christopherson
2021-10-15 16:23 ` Paolo Bonzini
2021-10-15 16:36 ` Sean Christopherson
2021-10-15 17:50 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YWRJwZF1toUuyBdC@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.