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

[Cornelia Huck]

On Thu, Jul 20 2023, Jing Zhang <jingzhangos at google.com> wrote:

> Hi Cornelia,
>
> On Thu, Jul 20, 2023 at 1:52 AM Cornelia Huck <cohuck at redhat.com> wrote:
>>
>> On Tue, Jul 18 2023, Jing Zhang <jingzhangos at google.com> wrote:
>>
>> > All valid fields in ID_AA64DFR0_EL1 and ID_DFR0_EL1 are writable
>> > from usrespace with this change.
>>
>> Typo: s/usrespace/userspace/
> Thanks.
>>
>> >
>> > Signed-off-by: Jing Zhang <jingzhangos at google.com>
>> > ---
>> >  arch/arm64/kvm/sys_regs.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index 053d8057ff1e..f33aec83f1b4 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -2008,7 +2008,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>> >         .set_user = set_id_dfr0_el1,
>> >         .visibility = aa32_id_visibility,
>> >         .reset = read_sanitised_id_dfr0_el1,
>> > -       .val = ID_DFR0_EL1_PerfMon_MASK, },
>> > +       .val = GENMASK(63, 0), },
>> >       ID_HIDDEN(ID_AFR0_EL1),
>> >       AA32_ID_SANITISED(ID_MMFR0_EL1),
>> >       AA32_ID_SANITISED(ID_MMFR1_EL1),
>> > @@ -2057,7 +2057,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>> >         .get_user = get_id_reg,
>> >         .set_user = set_id_aa64dfr0_el1,
>> >         .reset = read_sanitised_id_aa64dfr0_el1,
>> > -       .val = ID_AA64DFR0_EL1_PMUVer_MASK, },
>> > +       .val = GENMASK(63, 0), },
>> >       ID_SANITISED(ID_AA64DFR1_EL1),
>> >       ID_UNALLOCATED(5,2),
>> >       ID_UNALLOCATED(5,3),
>>
>> How does userspace find out whether a given id reg is actually writable,
>> other than trying to write to it?
>>
> 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 :)