Re: [PATCH 0/4] Introduce ARM MTE feature
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?
Remember that, unlike QEMU, we don't have the luxury of erasing
mistakes from our public interfaces, ever :)
libvirt should probably not turn it on by default (I haven't
checked
what the patches actually do ;)
[Also, I don't think there is any readily available hardware supporting
MTE yet; I have been testing my code on the simulator...]
Agreed on not enabling it by default, especially considering the
current hardware support situation. The feature remains disabled by
default after the patches that have been merged.
--
Andrea Bolognani / Red Hat / Virtualization