On Tue, May 13 2025, Daniel P. Berrangé <berra...@redhat.com> wrote:
> On Mon, Apr 14, 2025 at 06:38:47PM +0200, Cornelia Huck wrote: >> From: Eric Auger <eric.au...@redhat.com> >> >> If the interface for writable ID registers is available, expose uint64 >> SYSREG properties for writable ID reg fields exposed by the host >> kernel. Properties are named SYSREG_<REG>_<FIELD> with REG and FIELD >> being those used in linux arch/arm64/tools/sysreg. This done by >> matching the writable fields retrieved from the host kernel against the >> generated description of sysregs. >> >> An example of invocation is: >> -cpu host,SYSREG_ID_AA64ISAR0_EL1_DP=0x0 >> which sets DP field of ID_AA64ISAR0_EL1 to 0. > > For the value you are illustrating 0x0 - is this implying that > all the flags take an arbitrary integer hex value ? > > This would be different from x86, where CPU feature flags are > a boolean on/off state. Most of the fields are 4 bits, the allowed values vary (there are also some fields that are single bits, or wider.) The FEAT_xxx values (which can be expressed via ID register fields, or a combination thereof) are mostly boolean, but there are also some of them that can take values. We could cook up pseudo-features that are always on/off, but I don't like that approach: they would be QEMU only, whereas the ID register fields and FEAT_xxx features are all defined in the Arm documentation. An additional difference from x86 would be that FEAT_xxx featues are not neccessarily configurable (only if the host kernel supports changing the ID register field(s) backing the feature.)