All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Vitaly Kuznetsov" <vkuznets@redhat.com>,
	"Wanpeng Li" <wanpengli@tencent.com>,
	"Jim Mattson" <jmattson@google.com>,
	"Joerg Roedel" <joro@8bytes.org>,
	"KVM list" <kvm@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Adam Borowski" <kilobyte@angband.pl>,
	"David Hildenbrand" <david@redhat.com>
Subject: Re: [PATCH 1/2] KVM: MMU: Do not treat ZONE_DEVICE pages as being reserved
Date: Wed, 6 Nov 2019 12:34:10 -0800	[thread overview]
Message-ID: <CAPcyv4heVU94fVGJyaddpb0LN37sUCPJ5x9SYzt2P_DidXXc=Q@mail.gmail.com> (raw)
In-Reply-To: <20191106202627.GF16249@linux.intel.com>

On Wed, Nov 6, 2019 at 12:26 PM Sean Christopherson
<sean.j.christopherson@intel.com> wrote:
>
> On Wed, Nov 06, 2019 at 10:04:22AM -0800, Dan Williams wrote:
> > On Wed, Nov 6, 2019 at 9:07 AM Sean Christopherson
> > <sean.j.christopherson@intel.com> wrote:
> > >
> > > Explicitly exempt ZONE_DEVICE pages from kvm_is_reserved_pfn() and
> > > instead manually handle ZONE_DEVICE on a case-by-case basis.  For things
> > > like page refcounts, KVM needs to treat ZONE_DEVICE pages like normal
> > > pages, e.g. put pages grabbed via gup().  But KVM needs special handling
> > > in other flows where ZONE_DEVICE pages lack the underlying machinery,
> > > e.g. when setting accessed/dirty bits and shifting refcounts for
> > > transparent huge pages.
> > >
> > > This fixes a hang reported by Adam Borowski[*] in dev_pagemap_cleanup()
> > > when running a KVM guest backed with /dev/dax memory, as KVM straight up
> > > doesn't put any references to ZONE_DEVICE pages acquired by gup().
> > >
> > > [*] http://lkml.kernel.org/r/20190919115547.GA17963@angband.pl
> > >
> > > Reported-by: Adam Borowski <kilobyte@angband.pl>
> > > Debugged-by: David Hildenbrand <david@redhat.com>
> > > Cc: Dan Williams <dan.j.williams@intel.com>
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> > > ---
> > >  arch/x86/kvm/mmu.c       |  8 ++++----
> > >  include/linux/kvm_host.h |  1 +
> > >  virt/kvm/kvm_main.c      | 19 +++++++++++++++----
> > >  3 files changed, 20 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> > > index 24c23c66b226..bf82b1f2e834 100644
> > > --- a/arch/x86/kvm/mmu.c
> > > +++ b/arch/x86/kvm/mmu.c
> > > @@ -3306,7 +3306,7 @@ static void transparent_hugepage_adjust(struct kvm_vcpu *vcpu,
> > >          * here.
> > >          */
> > >         if (!is_error_noslot_pfn(pfn) && !kvm_is_reserved_pfn(pfn) &&
> > > -           level == PT_PAGE_TABLE_LEVEL &&
> > > +           !kvm_is_zone_device_pfn(pfn) && level == PT_PAGE_TABLE_LEVEL &&
> > >             PageTransCompoundMap(pfn_to_page(pfn)) &&
> > >             !mmu_gfn_lpage_is_disallowed(vcpu, gfn, PT_DIRECTORY_LEVEL)) {
> > >                 unsigned long mask;
> > > @@ -5914,9 +5914,9 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm,
> > >                  * the guest, and the guest page table is using 4K page size
> > >                  * mapping if the indirect sp has level = 1.
> > >                  */
> > > -               if (sp->role.direct &&
> > > -                       !kvm_is_reserved_pfn(pfn) &&
> > > -                       PageTransCompoundMap(pfn_to_page(pfn))) {
> > > +               if (sp->role.direct && !kvm_is_reserved_pfn(pfn) &&
> > > +                   !kvm_is_zone_device_pfn(pfn) &&
> > > +                   PageTransCompoundMap(pfn_to_page(pfn))) {
> > >                         pte_list_remove(rmap_head, sptep);
> > >
> > >                         if (kvm_available_flush_tlb_with_range())
> > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > > index a817e446c9aa..4ad1cd7d2d4d 100644
> > > --- a/include/linux/kvm_host.h
> > > +++ b/include/linux/kvm_host.h
> > > @@ -966,6 +966,7 @@ int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu);
> > >  void kvm_vcpu_kick(struct kvm_vcpu *vcpu);
> > >
> > >  bool kvm_is_reserved_pfn(kvm_pfn_t pfn);
> > > +bool kvm_is_zone_device_pfn(kvm_pfn_t pfn);
> > >
> > >  struct kvm_irq_ack_notifier {
> > >         struct hlist_node link;
> > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > > index b8534c6b8cf6..0a781b1fb8f0 100644
> > > --- a/virt/kvm/kvm_main.c
> > > +++ b/virt/kvm/kvm_main.c
> > > @@ -151,12 +151,23 @@ __weak int kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
> > >
> > >  bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
> > >  {
> > > +       /*
> > > +        * ZONE_DEVICE pages currently set PG_reserved, but from a refcounting
> > > +        * perspective they are "normal" pages, albeit with slightly different
> > > +        * usage rules.
> > > +        */
> > >         if (pfn_valid(pfn))
> > > -               return PageReserved(pfn_to_page(pfn));
> > > +               return PageReserved(pfn_to_page(pfn)) &&
> > > +                      !is_zone_device_page(pfn_to_page(pfn));
> >
> > This is racy unless you can be certain that the pfn and resulting page
> > has already been pinned by get_user_pages(). This is why I told David
> > to steer clear of adding more is_zone_device_page() usage, it's
> > difficult to audit. Without an existing pin the metadata to determine
> > whether a page is ZONE_DEVICE or not could be in the process of being
> > torn down.
>
> Ouch, that's brutal.  Makes perfect sense why you'd want to avoid
> is_zone_device_page().
>
> > Ideally KVM would pass around a struct { struct page *page,
> > unsigned long pfn } tuple so it would not have to do this "recall
> > context" dance on every pfn operation.
>
> Implementing something of that nature is doable, but it's going to be a
> significant overhaul as it will require updating every architecture.  So
> yeah, let's go with David's suggestion of fixing the immediate bug with
> your quick and dirty change and punting a more complete rework to future
> cleanup.  There are still multiple KVM flows that don't correctly handle
> ZONE_DEVICE, especially outside of x86, but I don't think there's a quick
> fix for those issues.

Sounds like a plan, I'll rework that fix with the change you suggested
and submit a formal one.

  reply	other threads:[~2019-11-06 20:34 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06 17:07 [PATCH 0/2] KVM: MMU: Fix a refcount bug with ZONE_DEVICE pages Sean Christopherson
2019-11-06 17:07 ` [PATCH 1/2] KVM: MMU: Do not treat ZONE_DEVICE pages as being reserved Sean Christopherson
2019-11-06 17:14   ` Paolo Bonzini
2019-11-06 17:46     ` Sean Christopherson
2019-11-06 18:04   ` Dan Williams
2019-11-06 20:26     ` Sean Christopherson
2019-11-06 20:34       ` Dan Williams [this message]
2019-11-06 21:09     ` Paolo Bonzini
2019-11-06 21:30       ` Sean Christopherson
2019-11-06 23:20       ` Dan Williams
2019-11-06 23:39         ` Sean Christopherson
2019-11-07  0:01           ` Dan Williams
2019-11-07  5:48             ` Dan Williams
2019-11-07 11:12               ` Paolo Bonzini
2019-11-07 15:36                 ` Dan Williams
2019-11-07 15:58                   ` Sean Christopherson
2019-11-09  1:43                     ` Sean Christopherson
2019-11-09  2:00                       ` Dan Williams
2019-11-11 18:27                         ` Sean Christopherson
2019-11-11 19:15                           ` Paolo Bonzini
2019-11-12  0:51                           ` Dan Williams
2019-11-12 10:19                             ` Paolo Bonzini
2019-11-12 16:57                               ` Sean Christopherson
2019-11-06 17:07 ` [PATCH 2/2] KVM: x86/mmu: Add helper to consolidate huge page promotion Sean Christopherson
2019-11-06 17:22   ` 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='CAPcyv4heVU94fVGJyaddpb0LN37sUCPJ5x9SYzt2P_DidXXc=Q@mail.gmail.com' \
    --to=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kilobyte@angband.pl \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=sean.j.christopherson@intel.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.