On Fri, May 16, 2025 at 04:51:34PM +0200, Cornelia Huck wrote: > 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.
For "host" model that's probably not the end of the world. Apps have already given up strong guarantee of migration compat by using 'host' CPU and so in that context libvirt's feature comparison can assume the underlying silicon is a match and just compare features. In that sense the ability to list features and baseline two cpus lets you guarantee that whatever CPU you boot the guest on, will have at least those requested features. That's useful, even if it does not give you a strong migration compat guarantee. Doing better would require info on non-writable features, and possibly even that might not be sufficient to guarantee compat With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
