[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.
- [PATCH RFCv2 00/20] kvm/arm: Introduce a customizable aarch64 KVM host model, Cornelia Huck, 2024/12/06
- [PATCH RFCv2 01/20] kvm: kvm_get_writable_id_regs, Cornelia Huck, 2024/12/06
- [PATCH RFCv2 02/20] arm/cpu: Add sysreg definitions in cpu-sysregs.h, Cornelia Huck, 2024/12/06
- [PATCH RFCv2 03/20] arm/cpu: Store aa64isar0 into the idregs arrays, Cornelia Huck, 2024/12/06
- [PATCH RFCv2 04/20] arm/cpu: Store aa64isar1/2 into the idregs array, Cornelia Huck, 2024/12/06
- [PATCH RFCv2 07/20] arm/cpu: Store aa64drf0/1 into the idregs array, Cornelia Huck, 2024/12/06
- [PATCH RFCv2 05/20] arm/cpu: Store aa64drf0/1 into the idregs array, Cornelia Huck, 2024/12/06
- [PATCH RFCv2 06/20] arm/cpu: Store aa64mmfr0-3 into the idregs array, Cornelia Huck, 2024/12/06
- [PATCH RFCv2 08/20] arm/cpu: Store aa64smfr0 into the idregs array, Cornelia Huck, 2024/12/06
- [PATCH RFCv2 09/20] arm/cpu: Store id_isar0-7 into the idregs array, Cornelia Huck, 2024/12/06
- [PATCH RFCv2 11/20] arm/cpu: Store id_dfr0/1 into the idregs array, Cornelia Huck, 2024/12/06
- [PATCH RFCv2 12/20] arm/cpu: Store id_mmfr0-5 into the idregs array, Cornelia Huck, 2024/12/06
- [PATCH RFCv2 13/20] arm/cpu: Add infra to handle generated ID register definitions, Cornelia Huck, 2024/12/06