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.
Committing to any specific interface in libvirt at this point in time
feels premature, as it's pretty much guaranteed that it will no
longer fit once the questions above have been answered.
Fair enough, feel free to revert my patches.
Last but not least, the way detection has been implemented is not
accurate: as of today, QEMU does *not* support enabling MTE with KVM.
Patches adding this feature have been posted[1] and are going to be
merged soon, but even then just looking at the machine type property
is not going to be enough to determine whether MTE can actually be
used.
Then it's a matter of:
diff --git i/hw/arm/virt.c w/hw/arm/virt.c
index b99ae18501..ead3555dfa 100644
--- i/hw/arm/virt.c
+++ w/hw/arm/virt.c
@@ -3111,11 +3111,13 @@ static void virt_machine_class_init(ObjectClass *oc, void *data)
"Set on/off to enable/disable reporting
host memory errors "
"to a KVM guest using ACPI and guest
external abort exceptions");
- object_class_property_add_bool(oc, "mte", virt_get_mte, virt_set_mte);
- object_class_property_set_description(oc, "mte",
- "Set on/off to enable/disable emulating a
"
- "guest CPU which implements the ARM
"
- "Memory Tagging Extension");
+ if (kvm_arm_mte_supported()) {
+ object_class_property_add_bool(oc, "mte", virt_get_mte, virt_set_mte);
+ object_class_property_set_description(oc, "mte",
+ "Set on/off to enable/disable
emulating a "
+ "guest CPU which implements the ARM
"
+ "Memory Tagging Extension");
+ }
object_class_property_add_bool(oc, "its", virt_get_its,
virt_set_its);
Or querying KVM extensions in libvirt (we already do that for some features).
Michal