Re: [PATCH 0/4] Introduce ARM MTE feature
On Wed, May 17 2023, Andrea Bolognani <abologna(a)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 :)