From: Alex Williamson <alex.williamson@redhat.com>
To: "Cédric Le Goater" <clg@redhat.com>
Cc: qemu-devel@nongnu.org, peterx@redhat.com
Subject: Re: [PATCH 2/2] vfio/helpers: Align mmaps
Date: Wed, 23 Oct 2024 07:55:15 -0600 [thread overview]
Message-ID: <20241023075515.352efa25.alex.williamson@redhat.com> (raw)
In-Reply-To: <d65cf179-21e6-4cda-baae-57fde73807cf@redhat.com>
On Wed, 23 Oct 2024 14:44:19 +0200
Cédric Le Goater <clg@redhat.com> wrote:
> On 10/22/24 22:08, Alex Williamson wrote:
> > Thanks to work by Peter Xu, support is introduced in Linux v6.12 to
> > allow pfnmap insertions at PMD and PUD levels of the page table. This
> > means that provided a properly aligned mmap, the vfio driver is able
> > to map MMIO at significantly larger intervals than PAGE_SIZE. For
> > example on x86_64 (the only architecture currently supporting huge
> > pfnmaps for PUD), rather than 4KiB mappings, we can map device MMIO
> > using 2MiB and even 1GiB page table entries.
> >
> > Typically mmap will already provide PMD aligned mappings, so devices
> > with moderately sized MMIO ranges, even GPUs with standard 256MiB BARs,
> > will already take advantage of this support. However in order to better
> > support devices exposing multi-GiB MMIO, such as 3D accelerators or GPUs
> > with resizable BARs enabled, we need to manually align the mmap.
> >
> > There doesn't seem to be a way for userspace to easily learn about PMD
> > and PUD mapping level sizes, therefore this takes the simple approach
> > to align the mapping to the power-of-two size of the region, up to 1GiB,
> > which is currently the maximum alignment we care about.
>
>
> Couldn't we inspect /sys/kernel/mm/hugepages/ to get the sizes ?
Sifting through sysfs doesn't seem like a great solution if we want to
support running QEMU in a sandbox with limited access, but also
hugepage sizes don't seem to strictly map to PMD and PUD page table
levels on all platforms. For instance ARM seems to support an
assortment of hugepage sizes, some of which appear to be available via
contiguous page hinting rather than actual page table level sizes. At
that point we're still approximating the actual discrete mapping
intervals, but at a substantial increase in complexity, unless we
already have dependencies and existing code that can be leveraged.
> > Cc: Peter Xu <peterx@redhat.com>
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
>
> anyhow,
>
>
> Reviewed-by: Cédric Le Goater <clg@redhat.com>
Thanks!
Alex
> > ---
> > hw/vfio/helpers.c | 32 ++++++++++++++++++++++++++++++--
> > 1 file changed, 30 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/vfio/helpers.c b/hw/vfio/helpers.c
> > index b9e606e364a2..913796f437f8 100644
> > --- a/hw/vfio/helpers.c
> > +++ b/hw/vfio/helpers.c
> > @@ -27,6 +27,7 @@
> > #include "trace.h"
> > #include "qapi/error.h"
> > #include "qemu/error-report.h"
> > +#include "qemu/units.h"
> > #include "monitor/monitor.h"
> >
> > /*
> > @@ -406,8 +407,35 @@ int vfio_region_mmap(VFIORegion *region)
> > prot |= region->flags & VFIO_REGION_INFO_FLAG_WRITE ? PROT_WRITE : 0;
> >
> > for (i = 0; i < region->nr_mmaps; i++) {
> > - region->mmaps[i].mmap = mmap(NULL, region->mmaps[i].size, prot,
> > - MAP_SHARED, region->vbasedev->fd,
> > + size_t align = MIN(1ULL << ctz64(region->mmaps[i].size), 1 * GiB);
> > + void *map_base, *map_align;
> > +
> > + /*
> > + * Align the mmap for more efficient mapping in the kernel. Ideally
> > + * we'd know the PMD and PUD mapping sizes to use as discrete alignment
> > + * intervals, but we don't. As of Linux v6.12, the largest PUD size
> > + * supporting huge pfnmap is 1GiB (ARCH_SUPPORTS_PUD_PFNMAP is only set
> > + * on x86_64). Align by power-of-two size, capped at 1GiB.
> > + *
> > + * NB. qemu_memalign() and friends actually allocate memory, whereas
> > + * the region size here can exceed host memory, therefore we manually
> > + * create an oversized anonymous mapping and clean it up for alignment.
> > + */
> > + map_base = mmap(0, region->mmaps[i].size + align, PROT_NONE,
> > + MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> > + if (map_base == MAP_FAILED) {
> > + ret = -errno;
> > + goto no_mmap;
> > + }
> > +
> > + map_align = (void *)ROUND_UP((uintptr_t)map_base, (uintptr_t)align);
> > + munmap(map_base, map_align - map_base);
> > + munmap(map_align + region->mmaps[i].size,
> > + align - (map_align - map_base));
> > +
> > + region->mmaps[i].mmap = mmap(map_align, region->mmaps[i].size, prot,
> > + MAP_SHARED | MAP_FIXED,
> > + region->vbasedev->fd,
> > region->fd_offset +
> > region->mmaps[i].offset);
> > if (region->mmaps[i].mmap == MAP_FAILED) {
>
next prev parent reply other threads:[~2024-10-23 13:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-22 20:08 [PATCH 0/2] vfio: Align mmaps Alex Williamson
2024-10-22 20:08 ` [PATCH 1/2] vfio/helpers: Refactor vfio_region_mmap() error handling Alex Williamson
2024-10-22 21:44 ` Peter Xu
2024-10-23 9:13 ` Cédric Le Goater
2024-10-22 20:08 ` [PATCH 2/2] vfio/helpers: Align mmaps Alex Williamson
2024-10-22 21:50 ` Peter Xu
2024-10-23 12:44 ` Cédric Le Goater
2024-10-23 13:55 ` Alex Williamson [this message]
2024-10-23 15:08 ` [PATCH 0/2] vfio: " Cédric Le Goater
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=20241023075515.352efa25.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=clg@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).