All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Donnefort <vdonnefort@google.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: will@kernel.org, julien.thierry.kdev@gmail.com,
	kvm@vger.kernel.org, kvmarm@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, maz@kernel.org,
	oliver.upton@linux.dev, alexandru.elisei@arm.com,
	andre.przywara@arm.com
Subject: Re: [PATCH kvmtool] arm64: THPs for systems with pages bigger than 4K
Date: Thu, 22 Oct 2026 09:31:33 +0100	[thread overview]
Message-ID: <atnJ5RdWkGQ9QZgQ@google.com> (raw)
In-Reply-To: <16679dd3-c168-4dee-bb9d-da9b0e3416cf@arm.com>

On Tue, Oct 20, 2026 at 03:43:08PM +0100, Suzuki K Poulose wrote:
> On 19/10/2026 15:59, Vincent Donnefort wrote:
> > The THP support imposes an alignment of the memslot userspace address to
> > the size of a THP (PMD_SIZE). To do so, kvmtool overallocates the RAM
> > size and aligns it. However it assumes PMD_SIZE is 2MiB, which is only
> > true on 4KiB page systems.
> > 
> > Use a huge-page size, based on the system page size. This value can be
> > massive for a 64KiB page system, so skip the alignment if we couldn't
> > even install one THP.
> > 
> > Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
> > 
> > diff --git a/arm64/kvm.c b/arm64/kvm.c
> > index 36b3284e4a92..2c01dc32fa9a 100644
> > --- a/arm64/kvm.c
> > +++ b/arm64/kvm.c
> > @@ -18,6 +18,8 @@
> >   #include <asm/image.h>
> > +#define HUGEPAGE_SIZE (PAGE_SIZE * (PAGE_SIZE / 8UL))
> > +
> >   static struct arm64_image_header *kernel_header;
> >   struct kvm_ext kvm_req_ext[] = {
> > @@ -35,20 +37,23 @@ bool kvm__arch_cpu_supports_vm(void)
> >   void kvm__init_ram(struct kvm *kvm)
> >   {
> > -	u64 phys_start, phys_size;
> > +	u64 phys_start, phys_size, ram_alloc_align = SZ_64K;
> >   	void *host_mem;
> >   	int err;
> >   	/*
> > -	 * Allocate guest memory. We must align our buffer to 64K to
> > -	 * correlate with the maximum guest page size for virtio-mmio.
> > -	 * If using THP, then our minimal alignment becomes 2M.
> > -	 * 2M trumps 64K, so let's go with that.
> > +	 * Allocate guest memory. We must align our buffer to 64K to correlate
> > +	 * with the maximum guest page size for virtio-mmio. If using THP, then
> > +	 * our minimal alignment trumps 64K, so let's go with that.
> >   	 */
> >   	kvm->ram_size = kvm->cfg.ram_size;
> >   	kvm->arch.ram_alloc_size = kvm->ram_size;
> > -	if (!kvm->cfg.hugetlbfs_path)
> > -		kvm->arch.ram_alloc_size += SZ_2M;
> > +	if (!kvm->cfg.hugetlbfs_path) {
> > +		if (kvm->ram_size >= HUGEPAGE_SIZE)
> > +			ram_alloc_align = HUGEPAGE_SIZE;
> 
> There is logic in builtin-run.c to detect the host_ram_size(), could we
> use that instead to decide if we should apply this alignment ? Or retry
> the RAM allocation without the alignment on failure ?

As the mmap() sets MAP_NORESERVE, I believe it is only reserving address space,
I don't think a failure is expected because we increase the size of that
reservation or did I miss anything?

> 
> It doesn't look like a good idea to hard code this based just on the
> requested RAM size.

The idea is just if we know the guest doesn't have enough RAM to install at
least one THP, then there is no need over-mmap. But it isn't saving anything
really so perhaps I may as well drop it?

> 
> Cheers
> Suzuki
> 
> 

Thanks for having a look,

-- 
Vincent

> 
> > +
> > +		kvm->arch.ram_alloc_size += ram_alloc_align;
> > +	}
> >   	if (kvm->cfg.arch.guest_memfd)
> >   		kvm->arch.ram_alloc_start = mmap_guest_memfd(kvm,
> > @@ -63,7 +68,7 @@ void kvm__init_ram(struct kvm *kvm)
> >   		    kvm->arch.ram_alloc_size, errno);
> >   	kvm->ram_start = (void *)ALIGN((unsigned long)kvm->arch.ram_alloc_start,
> > -					SZ_2M);
> > +					ram_alloc_align);
> >   	if (!kvm->cfg.arch.guest_memfd) {
> >   		madvise(kvm->arch.ram_alloc_start, kvm->arch.ram_alloc_size,
> > 
> > base-commit: f67bc0bdae9433a9cfd05e65ea2c1bb6102566d9
> 

      reply	other threads:[~2026-10-22  8:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 14:59 [PATCH kvmtool] arm64: THPs for systems with pages bigger than 4K Vincent Donnefort
2026-10-20 14:43 ` Suzuki K Poulose
2026-10-22  8:31   ` Vincent Donnefort [this message]

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=atnJ5RdWkGQ9QZgQ@google.com \
    --to=vdonnefort@google.com \
    --cc=alexandru.elisei@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    /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.