qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH RFCv2 02/20] arm/cpu: Add sysreg definitions in cpu-sysregs.h


From: Cornelia Huck
Subject: Re: [PATCH RFCv2 02/20] arm/cpu: Add sysreg definitions in cpu-sysregs.h
Date: Fri, 13 Dec 2024 17:16:58 +0100
User-agent: Notmuch/0.38.3 (https://notmuchmail.org)

On Thu, Dec 12 2024, Richard Henderson <richard.henderson@linaro.org> wrote:

> On 12/12/24 11:46, Eric Auger wrote:
>>> Do we really need anything beyond the defined registers, or even the
>>> defined registers for which qemu knows how to do anything?
>> what do you mean by "defined registers". The end goal is to be able to
>> tune any id reg that the kernel allows to write. So I guess we shall
>> encompass more regs than qemu currently handles.
>
> Defined registers as in "have an architected definition".
>
> E.g. there's no need to set any fields in (op0=0 op1=0 crn=0, crm=0, op2=1), 
> because that 
> isn't a defined system register.  It's in id register space sure, and almost 
> certainly 
> RAZ, but there's no call to either set it or represent it within qemu.
>
> Because you're working to a a symbolic command-line interface, with FEAT_FOO, 
> ID_REG.FIELD 
> names, qemu will (be extended to) handle every register named.

Going from the definitions, we have the potential to generate props for
anything that has been named (do we have named registers/fields that are not
architected?) Exposed on the command line are only those register fields
that are actually writable with the current KVM interface (see patch 18.)

I'm still not quite sure how to continue with FEAT_FOO, but I guess
we're still going to need the ID_REG.FIELD names in any case to handle
differences like DIC in CTR_EL0 mentioned elsewhere in this thread.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]