[PATCH 0/4] Introduce ARM MTE feature

[Cornelia Huck]

On Wed, May 17 2023, Andrea Bolognani <abologna at redhat.com> wrote:

> On Wed, May 17, 2023 at 11:19:17AM +0200, Cornelia Huck wrote:
>> This has been through some iterations... we (as in people working on
>> this in QEMU) need to decide on where to go with cpu features, cpu
>> models, etc. on Arm, but for now, it's a virt machine property.
>>
>> I have considered doing a GIC-like configuration, but for starters, the
>> kernel doesn't support configuring the MTE version yet... and I'm not
>> sure if configuring the MTE version (vs enabling/disabling MTE) should
>> not be modeled as a cpu property instead.
>>
>> Note that my patch adds a migration blocker when enabling MTE, so (1)
>> nothing bad regarding migration compatibility should happen yet
>
> Migration is of course the most obvious failure scenario, but one of
> the critical features offered by libvirt is guest ABI compatibility.
>
> If the user needs MTE3 specifically, rather than any MTE version, to
> be available to the guest OS, they'll configure the domain with
> something like
>
>   <mte version='3'/>
>
> and we need to be able to prevent such a VM from running on a host
> that doesn't have MTE3 support.
>
> So the fundamental question is, does the current libvirt interface
> paint us into a corner when it comes to implementing a more granular
> one later?

Given that an interface allowing to actually control the exposed version
is not likely to pop up in the next days, does it make sense to even try
to wire it up in libvirt right now?

>
> Remember that, unlike QEMU, we don't have the luxury of erasing
> mistakes from our public interfaces, ever :)