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

[Eric Auger]

On 12/12/24 10:36, Cornelia Huck wrote:
> 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.
>
Actually from a dev point of view I am not sure it changes much to have
either ARM spec rev baseline or CPU ref core named model.

One remark is that if you look at
https://developer.arm.com/documentation/109697/2024_09?lang=en
you will see there are quite a lot of spec revisions and quite a few of
them are actually meaningful in the light of currently avaiable and
relevant HW we want to address. What I would like to avoid is to be
obliged to look at all of them in a generic manner while we just want to
address few cpu ref models.

Also starting from the ARM spec rev baseline the end-user may need to
add more feature opt-ins to be close to a specific cpu model. So I
foresee extra complexity for the end-user.

But again I from a dev pov it shouldn't change much and we should end up
with a proto that illustrates the working model

Eric