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

[Cornelia Huck <cohuck@redhat.com>]

On Thu, Dec 12 2024, Eric Auger <eric.auger@redhat.com> wrote:

> 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.

Yes, exactly.

>
> 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.

For ref cores, it's easier to pick the ones that actually matter for a
specific use case, for arch exts I don't think we can avoid implementing
those we don't really care about. And yes, from the sample of cpus I've
looked at they seem to be much closer to a ref core than to an arch ext.