From: Sean Christopherson <seanjc@google.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: Chao Gao <chao.gao@intel.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
pbonzini@redhat.com
Subject: Re: [PATCH v2 1/6] KVM: x86/mmu: add a new mmu zap helper to indicate memtype changes
Date: Wed, 24 May 2023 07:50:24 -0700 [thread overview]
Message-ID: <ZG4kMKXKnQuQOTa7@google.com> (raw)
In-Reply-To: <ZG10zi6YtqGeik7u@yzhao56-desk.sh.intel.com>
On Wed, May 24, 2023, Yan Zhao wrote:
> On Tue, May 23, 2023 at 03:51:49PM -0700, Sean Christopherson wrote:
> > diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
> > index 3eb6e7f47e96..a67c28a56417 100644
> > --- a/arch/x86/kvm/mtrr.c
> > +++ b/arch/x86/kvm/mtrr.c
> > @@ -320,7 +320,7 @@ static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
> > struct kvm_mtrr *mtrr_state = &vcpu->arch.mtrr_state;
> > gfn_t start, end;
> >
> > - if (!tdp_enabled || !kvm_arch_has_noncoherent_dma(vcpu->kvm))
> > + if (!kvm_mmu_honors_guest_mtrrs(vcpu->kvm))
> Could we also add another helper kvm_mmu_cap_honors_guest_mtrrs(), which
> does not check kvm_arch_has_noncoherent_dma()?
>
> +static inline bool kvm_mmu_cap_honors_guest_mtrrs(struct kvm *kvm)
> +{
> + return !!shadow_memtype_mask;
> +}
>
> This is because in patch 4 I plan to do the EPT zap when
> noncoherent_dma_count goes from 1 to 0.
Hrm, the 1->0 transition is annoying. Rather than trying to capture the "everything
except non-coherent DMA" aspect, what about this?
mmu.c:
bool __kvm_mmu_honors_guest_mtrrs(struct kvm *kvm, bool vm_has_noncoherent_dma)
{
/*
* If the TDP is enabled, the host MTRRs are ignored by TDP
* (shadow_memtype_mask is non-zero), and the VM has non-coherent DMA
* (DMA doesn't snoop CPU caches), KVM's ABI is to honor the memtype
* from the guest's MTRRs so that guest accesses to memory that is
* DMA'd aren't cached against the guest's wishes.
*
* Note, KVM may still ultimately ignore guest MTRRs for certain PFNs,
* e.g. KVM will force UC memtype for host MMIO.
*/
return vm_has_noncoherent_dma && tdp_enabled && shadow_memtype_mask;
}
mmu.h:
bool __kvm_mmu_honors_guest_mtrrs(struct kvm *kvm, bool vm_has_noncoherent_dma);
static inline bool kvm_mmu_honors_guest_mtrrs(struct kvm *kvm)
{
return __kvm_mmu_honors_guest_mtrrs(kvm, kvm_arch_has_noncoherent_dma(kvm));
}
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 41d7bb51a297..ad0c43d7f532 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -13146,13 +13146,19 @@ EXPORT_SYMBOL_GPL(kvm_arch_has_assigned_device);
>
> void kvm_arch_register_noncoherent_dma(struct kvm *kvm)
> {
> - atomic_inc(&kvm->arch.noncoherent_dma_count);
> + if (atomic_inc_return(&kvm->arch.noncoherent_dma_count) == 1) {
> + if (kvm_mmu_cap_honors_guest_mtrrs(kvm))
> + kvm_zap_gfn_range(kvm, 0, ~0ULL);
No need for multiple if statements. Though rather than have identical code in
both the start/end paths, how about this? That provides a single location for a
comment. Or maybe first/last instead of start/end?
static void kvm_noncoherent_dma_start_or_end(struct kvm *kvm)
{
/* comment goes here. */
if (__kvm_mmu_honors_guest_mtrrs(kvm, true))
kvm_zap_gfn_range(kvm, 0, ~0ULL);
}
void kvm_arch_register_noncoherent_dma(struct kvm *kvm)
{
if (atomic_inc_return(&kvm->arch.noncoherent_dma_count) == 1)
kvm_noncoherent_dma_start_or_end(kvm);
}
EXPORT_SYMBOL_GPL(kvm_arch_register_noncoherent_dma);
void kvm_arch_unregister_noncoherent_dma(struct kvm *kvm)
{
if (!atomic_dec_return(&kvm->arch.noncoherent_dma_count))
kvm_noncoherent_dma_start_or_end(kvm);
}
EXPORT_SYMBOL_GPL(kvm_arch_unregister_noncoherent_dma);
next prev parent reply other threads:[~2023-05-24 14:50 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-09 13:48 [PATCH v2 0/6] KVM: x86/mmu: refine memtype related mmu zap Yan Zhao
2023-05-09 13:50 ` [PATCH v2 1/6] KVM: x86/mmu: add a new mmu zap helper to indicate memtype changes Yan Zhao
2023-05-10 5:30 ` Chao Gao
2023-05-10 8:06 ` Yan Zhao
2023-05-23 22:51 ` Sean Christopherson
2023-05-24 2:22 ` Yan Zhao
2023-05-24 14:50 ` Sean Christopherson [this message]
2023-05-25 10:14 ` Yan Zhao
2023-05-25 15:54 ` Sean Christopherson
2023-05-30 1:32 ` Yan Zhao
2023-05-30 9:48 ` Yan Zhao
2023-05-30 23:51 ` Sean Christopherson
2023-05-31 0:18 ` Yan Zhao
2023-05-09 13:51 ` [PATCH v2 2/6] KVM: x86/mmu: only zap EPT when guest CR0_CD changes Yan Zhao
2023-05-09 13:51 ` [PATCH v2 3/6] KVM: x86/mmu: only zap EPT when guest MTRR changes Yan Zhao
2023-05-10 5:39 ` Chao Gao
2023-05-10 8:00 ` Yan Zhao
2023-05-10 10:54 ` Huang, Kai
2023-05-11 0:15 ` Yan Zhao
2023-05-11 2:42 ` Huang, Kai
2023-05-11 2:31 ` Yan Zhao
2023-05-11 3:05 ` Huang, Kai
2023-05-09 13:52 ` [PATCH v2 4/6] KVM: x86/mmu: Zap all EPT leaf entries according noncoherent DMA count Yan Zhao
2023-05-09 13:53 ` [PATCH v2 5/6] KVM: x86: Keep a per-VM MTRR state Yan Zhao
2023-05-10 17:23 ` David Matlack
2023-05-21 3:44 ` Robert Hoo
2023-05-23 6:21 ` Yan Zhao
2023-05-24 0:13 ` Sean Christopherson
2023-05-24 11:03 ` Yan Zhao
2023-05-24 18:21 ` Sean Christopherson
2023-05-25 10:09 ` Yan Zhao
2023-05-25 14:53 ` Sean Christopherson
2023-05-26 7:54 ` Yan Zhao
2023-05-26 16:09 ` Sean Christopherson
2023-05-30 1:19 ` Yan Zhao
2023-05-25 7:21 ` Robert Hoo
2023-05-25 15:00 ` Sean Christopherson
2023-05-26 1:49 ` Robert Hoo
2023-05-09 13:53 ` [PATCH v2 6/6] KVM: x86/mmu: use per-VM based MTRR for EPT Yan Zhao
2023-05-24 0:15 ` [PATCH v2 0/6] KVM: x86/mmu: refine memtype related mmu zap Sean Christopherson
2023-05-24 11:04 ` Yan Zhao
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=ZG4kMKXKnQuQOTa7@google.com \
--to=seanjc@google.com \
--cc=chao.gao@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=yan.y.zhao@intel.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.