From: Yan Zhao <yan.y.zhao@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
Michael Roth <michael.roth@amd.com>
Subject: Re: [PATCH] KVM: x86/mmu: Prevent installing hugepages when mem attributes are changing
Date: Tue, 29 Apr 2025 09:23:13 +0800 [thread overview]
Message-ID: <aBAqAfBQRwP5Dx91@yzhao56-desk.sh.intel.com> (raw)
In-Reply-To: <aA-VrWyCkFuMWsaN@google.com>
On Mon, Apr 28, 2025 at 07:50:21AM -0700, Sean Christopherson wrote:
> On Mon, Apr 28, 2025, Yan Zhao wrote:
> > On Fri, Apr 25, 2025 at 05:10:56PM -0700, Sean Christopherson wrote:
> > > @@ -7686,6 +7707,37 @@ bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm,
> > > if (WARN_ON_ONCE(!kvm_arch_has_private_mem(kvm)))
> > > return false;
> > >
> > > + if (WARN_ON_ONCE(range->end <= range->start))
> > > + return false;
> > > +
> > > + /*
> > > + * If the head and tail pages of the range currently allow a hugepage,
> > > + * i.e. reside fully in the slot and don't have mixed attributes, then
> > > + * add each corresponding hugepage range to the ongoing invalidation,
> > > + * e.g. to prevent KVM from creating a hugepage in response to a fault
> > > + * for a gfn whose attributes aren't changing. Note, only the range
> > > + * of gfns whose attributes are being modified needs to be explicitly
> > > + * unmapped, as that will unmap any existing hugepages.
> > > + */
> > > + for (level = PG_LEVEL_2M; level <= KVM_MAX_HUGEPAGE_LEVEL; level++) {
> > > + gfn_t start = gfn_round_for_level(range->start, level);
> > > + gfn_t end = gfn_round_for_level(range->end - 1, level);
> > > + gfn_t nr_pages = KVM_PAGES_PER_HPAGE(level);
> > > +
> > > + if ((start != range->start || start + nr_pages > range->end) &&
> > > + start >= slot->base_gfn &&
> > > + start + nr_pages <= slot->base_gfn + slot->npages &&
> > > + !hugepage_test_mixed(slot, start, level))
> > Instead of checking mixed flag in disallow_lpage, could we check disallow_lpage
> > directly?
> >
> > So, if mixed flag is not set but disallow_lpage is 1, there's no need to update
> > the invalidate range.
> >
> > > + kvm_mmu_invalidate_range_add(kvm, start, start + nr_pages);
> > > +
> > > + if (end == start)
> > > + continue;
> > > +
> > > + if ((end + nr_pages) <= (slot->base_gfn + slot->npages) &&
> > > + !hugepage_test_mixed(slot, end, level))
> > if ((end + nr_pages > range->end) &&
Checking "end + nr_pages > range->end" is necessary?
if range->end equals to
"gfn_round_for_level(range->end - 1, level) + KVM_PAGES_PER_HPAGE(level)",
there's no need to do other checks to update the invalidate range.
> > ((end + nr_pages) <= (slot->base_gfn + slot->npages)) &&
> > !lpage_info_slot(gfn, slot, level)->disallow_lpage)
> >
> > ?
next prev parent reply other threads:[~2025-04-29 1:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-26 0:10 Sean Christopherson
2025-04-28 1:32 ` Yan Zhao
2025-04-28 14:50 ` Sean Christopherson
2025-04-29 1:09 ` Yan Zhao
2025-04-29 1:23 ` Yan Zhao [this message]
2025-04-29 12:57 ` Michael Roth
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=aBAqAfBQRwP5Dx91@yzhao56-desk.sh.intel.com \
--to=yan.y.zhao@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.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®