From: Haozhong Zhang <haozhong.zhang@intel.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: kvm@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
rkrcmar@redhat.com, Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
Dan Williams <dan.j.williams@intel.com>,
ivan.d.cuevas.escareno@intel.com, karthik.kumar@intel.com
Subject: Re: [PATCH 3/3] KVM: MMU: consider host cache type in MMIO pfn check
Date: Tue, 31 Oct 2017 15:35:04 +0800 [thread overview]
Message-ID: <20171031073504.xunicgpm57k7qyk2@hz-desktop> (raw)
In-Reply-To: <20171027084038.j45wuqcw5sb2h3ag@gmail.com>
On 10/27/17 10:40 +0200, Ingo Molnar wrote:
>
> * Haozhong Zhang <haozhong.zhang@intel.com> wrote:
>
> > By default, KVM treats a reserved page as for MMIO purpose, and maps
> > it to guest with UC memory type. However, some reserved pages are not
> > for MMIO, such as pages of DAX device (e.g., /dev/daxX.Y). Mapping
> > them with UC memory type will harm the performance. In order to
> > exclude those cases, we check the host cache mode in addition and only
> > treat UC/UC- pages as MMIO.
> >
> > Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
> > Reported-by: Cuevas Escareno, Ivan D <ivan.d.cuevas.escareno@intel.com>
> > Reported-by: Kumar, Karthik <karthik.kumar@intel.com>
> > ---
> > arch/x86/kvm/mmu.c | 32 +++++++++++++++++++++++++++++---
> > 1 file changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> > index 0b481cc9c725..d4c821a6df3d 100644
> > --- a/arch/x86/kvm/mmu.c
> > +++ b/arch/x86/kvm/mmu.c
> > @@ -2707,10 +2707,36 @@ static bool mmu_need_write_protect(struct kvm_vcpu *vcpu, gfn_t gfn,
> >
> > static bool kvm_is_mmio_pfn(kvm_pfn_t pfn)
> > {
> > - if (pfn_valid(pfn))
> > - return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn));
> > + bool is_mmio = true;
> >
> > - return true;
> > + if (pfn_valid(pfn)) {
> > + is_mmio = !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn));
> > +
> > + /*
> > + * By default, KVM treats a reserved page as for MMIO
> > + * purpose, and maps it to guest with UC memory type.
> > + * However, some reserved pages are not for MMIO, such
> > + * as pages of DAX device (e.g., /dev/daxX.Y). Mapping
> > + * them with UC memory type will harm the performance.
> > + * In order to exclude those cases, we check the host
> > + * cache mode in addition and only treat UC/UC- pages
> > + * as MMIO.
> > + *
> > + * track_pfn_insert() works only when PAT is enabled,
> > + * so add pat_enabled() here.
> > + */
> > + if (is_mmio && pat_enabled()) {
> > + pgprot_t prot;
> > + enum page_cache_mode cm;
> > +
> > + track_pfn_insert(NULL, &prot, kvm_pfn_to_pfn(pfn));
> > + cm = pgprot2cachemode(prot);
> > + is_mmio = (cm == _PAGE_CACHE_MODE_UC ||
> > + cm == _PAGE_CACHE_MODE_UC_MINUS);
> > + }
> > + }
> > +
> > + return is_mmio;
> > }
> >
> > static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
>
> s/harm the performance
> /harm performance>
>
> But I suspect the rest of the comment should be rewritten too to be more fluid.
I'll refactor the comment.
>
> Beyond that - I think instead of exposing these low level details a properly named
> helper function should be put into pat.c instead - and KVM can use that.
>
KVM only needs the memory type information, so lookup_memtype() in
pat.c is probably a better one to be exposed.
Haozhong
next prev parent reply other threads:[~2017-10-31 7:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-27 2:25 [PATCH 0/3] KVM: MMU: fix kvm_is_mmio_pfn() Haozhong Zhang
2017-10-27 2:25 ` [PATCH 1/3] x86/mm: expose track_pfn_insert() Haozhong Zhang
2017-10-27 2:25 ` [PATCH 2/3] KVM: add converters between pfn_t and kvm_pfn_t Haozhong Zhang
2017-10-27 2:25 ` [PATCH 3/3] KVM: MMU: consider host cache type in MMIO pfn check Haozhong Zhang
2017-10-27 8:40 ` Ingo Molnar
2017-10-31 7:35 ` Haozhong Zhang [this message]
2017-10-31 8:12 ` [PATCH 0/3] KVM: MMU: fix kvm_is_mmio_pfn() Xiao Guangrong
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=20171031073504.xunicgpm57k7qyk2@hz-desktop \
--to=haozhong.zhang@intel.com \
--cc=dan.j.williams@intel.com \
--cc=ivan.d.cuevas.escareno@intel.com \
--cc=karthik.kumar@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=x86@kernel.org \
--cc=xiaoguangrong.eric@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®