Re: [PATCH RFCv2 00/20] kvm/arm: Introduce a customizable aarch64 KVM host model

[Cornelia Huck <cohuck@redhat.com>]

On Thu, Dec 12 2024, Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Thu, Dec 12, 2024 at 09:12:33AM +0100, Eric Auger wrote:
>> Connie,
>> 
>> On 12/6/24 12:21, Cornelia Huck wrote:
>> > A respin/update on the aarch64 KVM cpu models. Also available at
>> > gitlab.com/cohuck/qemu arm-cpu-model-rfcv2
>
> snip
>
>> From a named model point of view, since I do not see much traction
>> upstream besides Red Hat use cases, targetting ARM spec revision
>> baselines may be overkill. Personally I would try to focus on above
>> models: AltraMax, AmpereOne, Grace, ... Or maybe the ARM cores they may
>> be derived from.
>
> If we target modelling of vendor named CPU models, then beware that
> we're opening the door to an very large set (potentially unbounded)
> of named CPU models over time. If we target ARM spec baselines then
> the set of named CPU models is fairly modest and grows slowly.
>
> Including ARM spec baselines will probably reduce the demand for
> adding vendor specific named models, though I expect we'll still
> end up wanting some, or possibly even many.
>
> Having some common baseline models is likely useful for mgmt
> applications in other ways though.
>
> Consider you mgmt app wants to set a CPU model that's common across
> heterogeneous hardware. They don't neccessarily want/need to be
> able to live migrate between heterogeneous CPUs, but for simplicity
> of configuration desire to set a single named CPU across all guests,
> irrespective of what host hey are launched on. The ARM spec baseline
> named models would give you that config simplicity.

If we use architecture extensions (i.e. Armv8.x/9.x) as baseline, I'm
seeing some drawbacks:
- a lot of work before we can address some specific use cases
- old models can get new optional features
- a specific cpu might have a huge set of optional features on top of
  the baseline model

Using a reference core such as Neoverse-V2 probably makes more sense
(easier to get started, less feature diff?) It would still make a good
starting point for a simple config.