From: Alex Williamson <alex.williamson@redhat.com>
To: Mahmoud Nagy Adam <mngyadam@amazon.de>
Cc: Jason Gunthorpe <jgg@ziepe.ca>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Kumar, Praveen" <pravkmr@amazon.de>,
"Woodhouse, David" <dwmw@amazon.co.uk>,
"nagy@khwaternagy.com" <nagy@khwaternagy.com>
Subject: Re: [RFC PATCH 0/9] vfio: Introduce mmap maple tree
Date: Thu, 28 Aug 2025 13:17:55 -0600 [thread overview]
Message-ID: <20250828131755.0b646987.alex.williamson@redhat.com> (raw)
In-Reply-To: <lrkyq8qj33jzv.fsf_-_@dev-dsk-mngyadam-1c-cb3f7548.eu-west-1.amazon.com>
On Thu, 28 Aug 2025 10:53:24 +0200
Mahmoud Nagy Adam <mngyadam@amazon.de> wrote:
> Hi all,
>
> Since it looks like creating alias regions is the path forward, I’d like
> to summarize the discussion to make sure we’re all aligned. From my
> understanding, the main steps are:
>
> - Introduce helpers to create compact offsets, likely leveraging
> mt. No changes to the vfio ops APIs are required, since the mt should
> live within the vfio struct itself.
I think we also established, or at least there were arguments in the
direction, that the maple tree is just an implementation detail of the
address space management. Obviously it contributes to compact and
efficient use of the address space, but for small numbers of alias
regions, we could continue to use the upper bits of the offset,
returning -ENOSPC if exceeded. I don't want to discourage the maple
tree, but it seems like it could be split to a separate series to me.
With the maple tree, an opt-in to continue to use the existing offsets
for the pre-defined vfio-pci region indexes could prove to be a useful
feature as well as we potentially learn about userspace drivers that
don't follow the ABI.
> - Add a WC flag to regions.
If we go the route of the DEVICE_FEATURE, we have the PROBE as an
option here. This might make sense if we to avoid redefining flags for
specific attributes between REGION_INFO and the new DEVICE_FEATURE uAPI.
> - Define a new UAPI for creating alias regions with new
> offsets. This UAPI should support aliasing existing regions as well
> as specifying additional flags such as WC.
I thought we'd discussed de-duplication, ie. if a user asks for an alias
with the same attributes as already defined, they get back the existing
region index/offset. I don't see the utility in creating an arbitrary
number of aliases with the same attributes. Thanks,
Alex
> - Enable WC support for mmap.
>
> I plan to start working on an RFC covering these points over the next
> 1–2 weeks.
>
> Thanks,
> MNAdam
>
>
>
> Amazon Web Services Development Center Germany GmbH
> Tamara-Danz-Str. 13
> 10243 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
> Sitz: Berlin
> Ust-ID: DE 365 538 597
next prev parent reply other threads:[~2025-08-28 19:18 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-04 10:39 [RFC PATCH 0/9] vfio: Introduce mmap maple tree Mahmoud Adam
2025-08-04 10:39 ` [RFC PATCH 1/9] vfio: add mmap maple tree to vfio Mahmoud Adam
2025-08-04 10:39 ` [RFC PATCH 2/9] vfio: add transient ops to support vfio mmap mt Mahmoud Adam
2025-08-04 10:39 ` [RFC PATCH 3/9] vfio-pci-core: rename vm operations Mahmoud Adam
2025-08-04 10:39 ` [RFC PATCH 4/9] vfio-pci-core: remove redundant offset calculations Mahmoud Adam
2025-08-04 10:39 ` [RFC PATCH 5/9] vfio-pci-core: add vfio_pci_mmap & helpers Mahmoud Adam
2025-08-04 10:39 ` [RFC PATCH 6/9] vfio-pci-core: support the new vfio ops Mahmoud Adam
2025-08-04 10:40 ` [RFC PATCH 7/9] vfio-pci: use " Mahmoud Adam
2025-08-04 10:40 ` [RFC PATCH 8/9] vfio: UAPI for setting mmap attributes Mahmoud Adam
2025-08-04 10:40 ` [RFC PATCH 9/9] vfio_pci_core: support mmap attrs uapi & WC Mahmoud Adam
2025-08-04 18:49 ` [RFC PATCH 0/9] vfio: Introduce mmap maple tree Alex Williamson
2025-08-04 20:09 ` Mahmoud Nagy Adam
2025-08-05 14:31 ` Jason Gunthorpe
2025-08-05 15:48 ` Mahmoud Nagy Adam
2025-08-05 18:50 ` [RFC " Jason Gunthorpe
2025-08-05 19:00 ` Alex Williamson
[not found] ` <80dc87730f694b2d6e6aabbd29df49cf3c7c44fb.camel@amazon.com>
[not found] ` <20250806115224.GB377696@ziepe.ca>
2025-08-07 8:12 ` Herrenschmidt, Benjamin
2025-08-07 19:06 ` Alex Williamson
2025-08-11 15:55 ` Jason Gunthorpe
2025-08-11 22:07 ` Alex Williamson
2025-08-12 0:30 ` Jason Gunthorpe
2025-08-12 19:26 ` Alex Williamson
2025-08-13 0:17 ` Jason Gunthorpe
2025-08-14 8:39 ` Mahmoud Nagy Adam
2025-08-14 9:52 ` Mahmoud Nagy Adam
2025-08-14 17:52 ` Alex Williamson
2025-08-28 8:53 ` Mahmoud Nagy Adam
2025-08-28 19:17 ` Alex Williamson [this message]
2025-08-07 8:13 ` Benjamin Herrenschmidt
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=20250828131755.0b646987.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=dwmw@amazon.co.uk \
--cc=jgg@ziepe.ca \
--cc=kvm@vger.kernel.org \
--cc=mngyadam@amazon.de \
--cc=nagy@khwaternagy.com \
--cc=pravkmr@amazon.de \
/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).