On Wed, May 14 2025, Daniel P. Berrangé <berra...@redhat.com> wrote:
> On Wed, May 14, 2025 at 05:36:58PM +0200, Cornelia Huck wrote: >> 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. > > Fortunately from a libvirt POV we can likely expand our config > to cope with hex values for arm features without too much > trouble. > >> >> 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.) > > Is the kernel able to tell us which ones are configurable and which > are not ? If so, it'd be helpful to expose this info in QAPI some > place. The kernel can tell us which ID register fields are writable (we won't generate properties if we don't.) For FEAT_xxx, this depends on how we'll end up handling them (maybe we should only expose them if all ID register bits backing them are actually writable.) What worries me a bit is that QEMU exposing a certain set of FEAT_xxx values could be interpreted as "those features are present, any other features aren't", while it is only the list of configurable features. Another issue: If libvirt is trying to baseline two cpus, it might end up creating a model that looks sane on paper, but migrations will fail because there are differences in non-writable bits. It would be much better if libvirt could detect beforehand that there was no common determinator. Not yet sure how to handle this.
