On Thu, Jul 20 2023, Jing Zhang <jingzhangos@xxxxxxxxxx> wrote:
> Hi Cornelia,
>
> On Thu, Jul 20, 2023 at 1:52 AM Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
>>
>> On Tue, Jul 18 2023, Jing Zhang <jingzhangos@xxxxxxxxxx> 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@xxxxxxxxxx>
>> > ---
>> > 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 :)
