Re: [PATCH v6 3/6] KVM: arm64: Enable writable for ID_AA64DFR0_EL1 and ID_DFR0_EL1

[Cornelia Huck <cohuck@redhat.com>]

On Fri, Jul 21 2023, Oliver Upton <oliver.upton@linux.dev> wrote:

> On Fri, Jul 21, 2023 at 11:22:35AM -0700, Jing Zhang wrote:
>> On Fri, Jul 21, 2023 at 2:31 AM Marc Zyngier <maz@kernel.org> wrote:
>> > My preference would be a single ioctl that returns the full list of
>> > writeable masks in the ID reg range. It is big, but not crazy big
>> > (1536 bytes, if I haven't messed up), and includes the non ID_*_EL1
>> > sysreg such as MPIDR_EL1, CTR_EL1, SMIDR_EL1.
>> Just want to double confirm that would the ioclt return the list of
>> only writable masks, not the list of {idreg_name, mask} pair? So, the
>> VMM will need to index idreg's writable mask by op1, CRm, op2?
>
> I generally agree with the approach Marc is proposing, but I wonder if
> it makes sense to have userspace ask the kernel for this information on
> a per-register basis.
>
> 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.

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.