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
