Re: [PATCH v3 08/10] arm/cpu: more customization for the kvm host cpu model

[Cornelia Huck <cohuck@redhat.com>]

On Fri, May 16 2025, Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Fri, May 16, 2025 at 04:51:34PM +0200, Cornelia Huck wrote:
>> On Wed, May 14 2025, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> 
>> > On Wed, May 14, 2025 at 05:36:58PM +0200, Cornelia Huck wrote:
>> >> On Tue, May 13 2025, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> >> 
>> >> > On Mon, Apr 14, 2025 at 06:38:47PM +0200, Cornelia Huck wrote:
>> >> >> From: Eric Auger <eric.auger@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

We'd probably want to use named models rather than 'host' for better
generic handling, but that's a whole different can of worms that I'd
prefer to keep closed right now.

OTOH, 'host' with some features tweaked is already useful if you want to
migrate across machines in a heterogeneous environment with known
players (i.e. you know that the various machines only differ in features
that you can actually configure.)