On Wed, May 17 2023, Michal Prívozník <mpriv...@redhat.com> wrote: > On 5/16/23 18:32, Andrea Bolognani wrote: >> On Tue, May 16, 2023 at 12:54:12PM +0200, Michal Privoznik wrote: >>> Michal Prívozník (4): >>> conf: Introduce MTE domain feature >>> qemu:: Introduce QEMU_CAPS_MACHINE_VIRT_MTE capability >>> qemu: Validate MTE feature >>> qemu: Generate command line for MTE feature >> >> I wish I'd managed to see this before it got reviewed and merged :/ > > We can still revert the patches, if needed. > >> >> For context, I have been following the development of the MTE feature >> in QEMU for a while, and was planning to work on the libvirt part >> later down the line. The main reason why I have not done so yet is >> that there are still some open questions about the interface. >> >> Specifically, MTE is not just a single thing: there are at least two >> versions that I'm aware of, MTE and MTE3. >> >> Right now, mte=on gives you MTE3 with TCG and whatever the host >> supports on KVM. Of course the latter is problematic when it comes to >> guaranteeing a stable guest ABI... I think a reasonable interface >> would be similar to what we have for GIC, with a 'version' attribute >> used to explicitly choose between MTE and MTE3, and some logic to >> fill in a reasonable value for the host by default. >> >> But there's also the question of whether MTE should be a machine >> property in the first place, rather than a CPU feature? > > I admit that my QEMU code base understanding is limited, but the patch > you've linked doesn't really expose any CPU feature that libvirt could > set. Instead, it enables MTE for KVM under the same API, i.e. -machine > virt,mte=on.
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, and (2) 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...]
