On 2026-09-01 at 14:53 +1000, Dave Airlie <[email protected]> wrote... > On Fri, 28 Aug 2026 at 13:36, Alistair Popple <[email protected]> wrote: > > > > Add an extensible info ioctl and use it to report basic GPU information. > > One of the first things userspace needs to know about a GPU is its > > architecture and implementation, so add that as the first field in the > > GPU info result. > > > > The ioctl selects an information type by ID and writes the result through > > a sized userspace buffer. The kernel truncates results to the supplied > > size, allowing information structures to grow and new logical information > > groups to be added without introducing new ioctls. > > > > > > This is a higher level for the future, I think we have two paths for > getparam type ioctl. > > Either we expose a big struct full of values with a add to the end > mentality or we keep a long list of value pairs, and userspace passes > in a list of value keys, and we return a list of the values.
There's already been a fair bit of back and forth on this on this series and this is where we ended up - a bunch of info ioctls returning big structs full of values. I did wonder if io_uring could be used by user-space to efficiently pass a list of value keys as that's trivial enough to add to drm[1] but perf wise didn't achieve much over just calling lots of ioctls, at least when I tested with a mock key/value type interface. [1] - https://lists.freedesktop.org/archives/dri-devel/2025-September/524469.html > I'm trying to think ahead towards native virtio context support, and I > think having the sequence, > > open > get_all_infos > create vm/channel > > might have the most optimal ioctl count but also let power management > avoid booting the GPU on every open if we never create a vm/channel. Power management is a good point - thus far all the info is cached in nova-core anyway so there shouldn't be much impact there regardless of what interface we choose. Thanks. - Alistair
