From: Alex Williamson <alex.williamson@redhat.com>
To: Mahmoud Nagy Adam <mngyadam@amazon.de>
Cc: Jason Gunthorpe <jgg@ziepe.ca>, <kvm@vger.kernel.org>,
<benh@kernel.crashing.org>, David Woodhouse <dwmw@amazon.co.uk>,
<pravkmr@amazon.de>, <nagy@khwaternagy.com>
Subject: Re: [RFC PATCH 0/9] vfio: Introduce mmap maple tree
Date: Tue, 5 Aug 2025 13:00:46 -0600 [thread overview]
Message-ID: <20250805130046.0527d0c7.alex.williamson@redhat.com> (raw)
In-Reply-To: <lrkyqpld96a8a.fsf_-_@dev-dsk-mngyadam-1c-cb3f7548.eu-west-1.amazon.com>
On Tue, 5 Aug 2025 17:48:05 +0200
Mahmoud Nagy Adam <mngyadam@amazon.de> wrote:
> Jason Gunthorpe <jgg@ziepe.ca> writes:
>
> > map2 should not exist, once you introduced a vfio_mmap_ops for free
> > then the mmap op should be placed into that structure.
>
> Does this mean dropping mmap op completely from vfio ops? I think we
> could update mmap op in vfio to have the vmmap structure, no?
>
> > ioctl2 is nasty, that should be the "new function op for
> > VFIO_DEVICE_GET_REGION_INFO" instead. We have been slowly moving
> > towards the core code doing more decode and dispatch of ioctls instead
> > of duplicating in drivers.
>
> ack.
>
> > I still stand by the patch plan I gave in the above email. Clean up
> > how VFIO_DEVICE_GET_REGION_INFO is handled by drivers and a maple tree
> > change will trivially drop on top.
> >
>
> but I think also prior of migrating to use packed offsets, we would need
> to fix the previous offset calculations, which means read & write ops
> also need to access the vmmap object to convert the offset.
>
>
>
> Another question is: since VFIO_DEVICE_GET_REGION_INFO will use mt and
> technically will create and return different cookie offset everytime
> it's called for the same region, do we expect that this will not break
> any userspace usage? I'm not sure but could be that some user usage
> relying on calling the get_region_info to produce the same offset as the
> initial call, instead of caching the region offset for example?
If we're returning a different cookie every time region_info is called
we're already on the wrong track. Userspace can call region_info an
arbitrary number of times and should get the same offset for the same
region every time. IMO we need an interface that triggers a new
mapping cookie to be created with specific mmap attributes. If we're
using region_info then we're dynamically introducing device specific
regions.
I think we're too concerned about this vmmap object, which ought to be
obtained via an offset into the maple tree in place of how we're using
fixed region indexes today. Some offsets will be pre-populated to
provide the existing regions we have today, optionally those
pre-populated entries may be at compatible offsets for broken
userspaces. New cookies will be dynamically created alongside. Thanks,
Alex
next prev parent reply other threads:[~2025-08-05 19:00 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 [this message]
[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
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=20250805130046.0527d0c7.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).