From: John Levon <john.levon@nutanix.com>
To: Alex Williamson <alex@shazbot.org>
Cc: "Cédric Le Goater" <clg@redhat.com>,
qemu-devel@nongnu.org,
"Alex Williamson" <alex.williamson@redhat.com>,
"John Johnson" <john.g.johnson@oracle.com>,
"Elena Ufimtseva" <elena.ufimtseva@oracle.com>,
"Jagannathan Raman" <jag.raman@oracle.com>
Subject: Re: [PULL 25/28] vfio: add region info cache
Date: Tue, 14 Oct 2025 16:36:52 +0200 [thread overview]
Message-ID: <aO5gBOLVt9R4BFnW@lent> (raw)
In-Reply-To: <20251014082937.7de6f960@shazbot.org>
On Tue, Oct 14, 2025 at 08:29:49AM -0600, Alex Williamson wrote:
> > Ah - is this documented somewhere? And do you have an example of where this
> > varies over the lifetime of a device currently?
>
> It's more the case that it's not specifically defined as static over
> the lifetime of the device. I don't think we want device spontaneously
> creating new regions, we have no device-check notification mechanism to
> userspace to reevaluate regions, but a user initiated action defined to
> create a new region seems like a fair vector where num_regions could be
> updated. Also the current working idea would be that regions are only
> added, not modified or deleted.
>
> > IOW, are these devices actually changing the num_regions value they report
> > sometime after initialization (namely, can it change after
> > vfio_device_prepare()) ?
>
> In theory, yes.
OK, thanks. So the question over whether there's an nvidia bug or not here seems
to be moot, since anyway to support this kind of case, we need the region cache
guardrails.
This means that such "dynamic" regions are never cached, but that's not a
specific issue for vfio-user at least.
I will prepare a patch if you can help test it, Cédric.
regards
john
next prev parent reply other threads:[~2025-10-14 14:39 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-09 13:12 [PULL 00/28] vfio queue Cédric Le Goater
2025-05-09 13:12 ` [PULL 01/28] vfio/container: ram discard disable helper Cédric Le Goater
2025-05-09 13:12 ` [PULL 02/28] vfio/container: reform vfio_container_connect cleanup Cédric Le Goater
2025-05-09 13:12 ` [PULL 03/28] vfio/container: vfio_container_group_add Cédric Le Goater
2025-05-09 13:12 ` [PULL 04/28] vfio/igd: Restrict legacy mode to Gen6-9 devices Cédric Le Goater
2025-05-09 13:12 ` [PULL 05/28] vfio/igd: Always emulate ASLS (OpRegion) register Cédric Le Goater
2025-05-09 13:12 ` [PULL 06/28] vfio/igd: Detect IGD device by OpRegion Cédric Le Goater
2025-05-09 13:12 ` [PULL 07/28] vfio/igd: Check vendor and device ID on GVT-g mdev Cédric Le Goater
2025-05-09 13:12 ` [PULL 08/28] vfio/igd: Check OpRegion support " Cédric Le Goater
2025-05-09 13:12 ` [PULL 09/28] vfio/igd: Enable OpRegion by default Cédric Le Goater
2025-05-09 13:12 ` [PULL 10/28] vfio/igd: Allow overriding GMS with 0xf0 to 0xfe on Gen9+ Cédric Le Goater
2025-05-09 13:13 ` [PULL 11/28] vfio/igd: Only emulate GGC register when x-igd-gms is set Cédric Le Goater
2025-05-09 13:13 ` [PULL 12/28] vfio/igd: Remove generation limitation for IGD passthrough Cédric Le Goater
2025-05-09 13:13 ` [PULL 13/28] linux-header: update-linux-header script changes Cédric Le Goater
2025-05-09 13:13 ` [PULL 14/28] linux-headers: Update to Linux v6.15-rc3 Cédric Le Goater
2025-05-09 13:13 ` [PULL 15/28] vfio: add vfio_device_prepare() Cédric Le Goater
2025-05-09 13:13 ` [PULL 16/28] vfio: add vfio_device_unprepare() Cédric Le Goater
2025-05-09 13:13 ` [PULL 17/28] vfio: add vfio_attach_device_by_iommu_type() Cédric Le Goater
2025-05-09 13:13 ` [PULL 18/28] vfio: add vfio_device_get_irq_info() helper Cédric Le Goater
2025-05-09 13:13 ` [PULL 19/28] vfio: consistently handle return value for helpers Cédric Le Goater
2025-05-09 13:13 ` [PULL 20/28] vfio: add strread/writeerror() Cédric Le Goater
2025-05-09 13:13 ` [PULL 21/28] vfio: add vfio_pci_config_space_read/write() Cédric Le Goater
2025-05-09 13:13 ` [PULL 22/28] vfio: add unmap_all flag to DMA unmap callback Cédric Le Goater
2025-05-09 13:13 ` [PULL 23/28] vfio: implement unmap all for DMA unmap callbacks Cédric Le Goater
2025-05-09 13:13 ` [PULL 24/28] vfio: add device IO ops vector Cédric Le Goater
2025-05-09 13:13 ` [PULL 25/28] vfio: add region info cache Cédric Le Goater
2025-10-14 13:16 ` Cédric Le Goater
2025-10-14 13:32 ` John Levon
2025-10-14 13:49 ` Alex Williamson
2025-10-14 13:58 ` Cédric Le Goater
2025-10-14 14:01 ` John Levon
2025-10-14 14:00 ` John Levon
2025-10-14 14:29 ` Alex Williamson
2025-10-14 14:36 ` John Levon [this message]
2025-05-09 13:13 ` [PULL 26/28] vfio: add read/write to device IO ops vector Cédric Le Goater
2025-05-09 13:13 ` [PULL 27/28] vfio: add vfio-pci-base class Cédric Le Goater
2025-05-09 13:13 ` [PULL 28/28] vfio/container: pass listener_begin/commit callbacks Cédric Le Goater
2025-05-10 18:36 ` [PULL 00/28] vfio queue Stefan Hajnoczi
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=aO5gBOLVt9R4BFnW@lent \
--to=john.levon@nutanix.com \
--cc=alex.williamson@redhat.com \
--cc=alex@shazbot.org \
--cc=clg@redhat.com \
--cc=elena.ufimtseva@oracle.com \
--cc=jag.raman@oracle.com \
--cc=john.g.johnson@oracle.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 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.