Hi Cornelia, On Mon, Jul 24, 2023 at 10:45:44AM +0200, Cornelia Huck wrote: > On Fri, Jul 21 2023, Oliver Upton <oliver.upton@xxxxxxxxx> wrote: > > What I had in mind was something similar to the KVM_GET_ONE_REG ioctl, > > but instead of returning the register value it'd return the mask of the > > register. This would keep the kernel implementation dead simple (I'm > > lazy) and more easily allow for future expansion in case we want to > > start describing more registers this way. Userspace would iterate the ID > > register space and ask the kernel for the mask of registers it wants to > > change. > > Hm... for userspace it might be easier to get one big list and then > parse it afterwards? Similar to what GET_REG_LIST does today. Possibly, but I felt like it was a bit different from GET_REG_LIST since this would actually be a list of key-value pairs (reg_id, mask) instead of a pure enumeration of IDs. My worry is that if/when we wind up describing more registers in this list-based ioctl then userspace is going to wind up traversing that structure a lot to find the register masks it actually cares about. > Are you thinking more of a KVM_GET_REG_INFO or so ioctl, that could > support different kinds of extra info (and might also make sense for > other architectures?) If we end up with something more versatile, it > might make sense going that route. TBH, I hadn't considered the extensibililty of a per-register ioctl, but that does seem like a good point. -- Thanks, Oliver
