On Fri, Jul 21 2023, Marc Zyngier <maz@xxxxxxxxxx> wrote:
> On Fri, 21 Jul 2023 09:38:23 +0100,
> Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
>>
>> On Thu, Jul 20 2023, Jing Zhang <jingzhangos@xxxxxxxxxx> wrote:
>> > No mechanism was provided to userspace to discover if a given idreg or
>> > any fields of a given idreg is writable. The write to a readonly idreg
>> > can also succeed (write ignored) without any error if what's written
>> > is exactly the same as what the idreg holds or if it is a write to
>> > AArch32 idregs on an AArch64-only system.
>>
>> Hm, I'm not sure that's a good thing for the cases where we want to
>> support mix-and-match userspace and kernels. Userspace may want to know
>> upfront whether it can actually tweak the contents of an idreg or not
>> (for example, in the context of using CPU models for compatibility), so
>> that it can reject or warn about certain configurations that may not
>> turn out as the user expects.
>>
>> > Not sure if it is worth adding an API to return the writable mask for
>> > idregs, since we want to enable the writable for all allocated
>> > unhidden idregs eventually.
>>
>> We'd enable any new idregs for writing from the start in the future, I
>> guess?
>>
>> I see two approaches here:
>> - add an API to get a list of idregs with their writable masks
>> - add a capability "you can write to all idregs whatever you'd expect to
>> be able to write there architecture wise", which would require to add
>> support for all idregs prior to exposing that cap
>>
>> The second option would be the easier one (if we don't manage to break
>> it in the future :)
>
> I'm not sure the last option is even possible. The architecture keeps
> allocating new ID registers in the op0==3, op1=={0, 1, 3}, CRn==0,
> CRm=={0-7}, op2=={0-7} space, so fields that were RES0 until then
> start having a non-0 value.
>
> This could lead to a situation where you move from a system that
> didn't know about ID_AA64MMFR6_EL1.XYZ to a system that advertises it,
> and for which the XYZ instruction has another behaviour. Bad things
> follow.
Hrm :(
>
> 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.
>
> It would allow the VMM to actively write zeroes to any writable ID
> register it doesn't know about, or for which it doesn't have anything
> to restore. It is also relatively future proof, as it covers
> *everything* the architecture has provisioned for the future (by the
> time that space is exhausted, I hope none of us will still be involved
> with this crap).
Famous last words :)
But yes, that should work. This wouldn't be the first ioctl returning a
long list, and the VMM would just call it once on VM startup to figure
things out anyway.
