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

[Cornelia Huck <cohuck@redhat.com>]

On Mon, Dec 16 2024, Cornelia Huck <cohuck@redhat.com> wrote:

> On Thu, Dec 12 2024, Eric Auger <eric.auger@redhat.com> wrote:
>
>> Connie,
>>
>> On 12/6/24 12:21, Cornelia Huck wrote:
>>> Whether it make sense to continue with the approach of tweaking values in
>>> the ID registers in general. If we want to be able to migrate between cpus
>>> that do not differ wildly, we'll encounter differences that cannot be
>>> expressed via FEAT_xxx -- e.g. when comparing various AmpereAltra Max systems,
>>> they only differ in parts of CTR_EL0 -- which is not a feature register, but
>>> a writable register.
>> In v1 most of the commenters said they would prefer to see FEAT props
>> instead of IDREG field props. I think we shall try to go in this
>> direction anyway. As you pointed out there will be some cases where FEAT
>> won't be enough (CTR_EL0 is a good example). So I tend to think the end
>> solution will be a mix of FEAT and ID reg field props.
>
> Some analysis of FEAT_xxx mappings:
> https://lore.kernel.org/qemu-devel/87ikstn8sc.fsf@redhat.com/
>
> (actually, ~190 of FEAT_xxx map to a single value in a single register,
> so mappings are easy other than the sheer amount of them)
>
> We probably should simply not support FEAT_xxx that are solely defined
> via dependencies.
>
> Some more real-world examples from some cpu pairings I had looked at:
> https://lore.kernel.org/qemu-devel/87ldx2krdp.fsf@redhat.com/
> (but also see Peter's follow-up, the endianness field is actually
> covered by a feature)
>
> The values-in-registers-not-covered-by-features we are currently aware
> of are:
> - number of breakpoints
> - PARange values
> - GIC
> - some fields in CTR_EL0
> (see also
> https://lore.kernel.org/qemu-devel/4fb49b5b02bb417399ee871b2c85bb35@huawei.com/
> for the latter two)

And the differences in GIC might be actually due to a GICv3 not being
configured, together with running a recent kernel, which will zero the
field. So we might actually already be able to handle it for most cases.

>
> Also, MIDR/REVIDR handling.
>
> Given that we'll need a mix if we support FEAT_xxx, should we mandate
> the FEAT_xxx syntax if there is a mapping and allow direct specification
> of register fields only if there is none, or allow them as alternatives
> (with proper priority handling, or alias handling?)
>
>>
>> Personally I would smoothly migrate what we can from ID reg field props
>> to FEAT props (maybe using prop aliases?), starting from the easiest 1-1
>> mappings and then adressing the FEAT that are more complex but are
>> explictly needed to enable the use cases we are interested in, at RedHat:
>> migration within Ampere AltraMax family, migration within NVidia Grace
>> family, migration within AmpereOne family and migration between Graviton3/4.
>
> For these, we'll already need the mix (my examples above all came from
> these use cases.)
>
> (Of course, the existing legacy props need to be expressed as well. I
> guess they should map to registers directly.)
>
>>
>> We have no info about other's use cases. If some of you want to see some
>> other live migration combinations addressed, please raise your voice.
>> Some CSPs may have their own LM solution/requirements but they don't use
>> qemu. So I think we shall concentrate on those use cases.
>>
>> You did the exercise to identify most prevalent patterns for FEAT to
>> IDREG fields mappings. I think we should now encode this conversion
>> table for those which are needed in above use cases.
>
> I'd focus on the actually needed features first, as otherwise it's
> really overwhelming.
>
>>
>> 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. According to the discussion we had with Marc in [1] it
>> seems it does not make sense to target migration between very
>> heterogeneous machines and Dan said we would prefer to avoid adding
>> plenty of feat add-ons to a named models. So I would rather be as close
>> as possible to a specific family definition.   
>
> Using e.g. Neoverse-V2 as a base currently looks most attractive to
> me -- going with Armv<x>.<y> would probably give a larger diff (although
> the diff for Graviton3/4 is pretty large anyway.)
>
>>
>> Thanks
>>
>> Eric
>>
>> [1]
>> https://lore.kernel.org/all/c879fda9-db5a-4743-805d-03c0acba8060@redhat.com/#r