On Tue, Feb 28, 2023 at 04:02:15PM +0100, Cornelia Huck wrote: > Introduce a new cpu feature flag to control MTE support. To preserve > backwards compatibility for tcg, MTE will continue to be enabled as > long as tag memory has been provided. > > If MTE has been enabled, we need to disable migration, as we do not > yet have a way to migrate the tags as well. Therefore, MTE will stay > off with KVM unless requested explicitly. > > Signed-off-by: Cornelia Huck <cohuck@xxxxxxxxxx> > --- > docs/system/arm/cpu-features.rst | 21 ++++++ > hw/arm/virt.c | 2 +- > target/arm/cpu.c | 18 ++--- > target/arm/cpu.h | 1 + > target/arm/cpu64.c | 110 +++++++++++++++++++++++++++++++ > target/arm/internals.h | 1 + > target/arm/kvm.c | 29 ++++++++ > target/arm/kvm64.c | 5 ++ > target/arm/kvm_arm.h | 19 ++++++ > target/arm/monitor.c | 1 + > 10 files changed, 194 insertions(+), 13 deletions(-) I've given a quick look with libvirt integration in mind, and everything seem fine. Specifically, MTE is advertised in the output of qom-list-properties both for max-arm-cpu and the latest virt-X.Y-machine, which means that libvirt can easily and reliably figure out whether MTE support is available. > +MTE CPU Property > +================ > + > +The ``mte`` property controls the Memory Tagging Extension. For TCG, it requires > +presence of tag memory (which can be turned on for the ``virt`` machine via > +``mte=on``). For KVM, it requires the ``KVM_CAP_ARM_MTE`` capability; until > +proper migration support is implemented, enabling MTE will install a migration > +blocker. Is it okay to use -machine virt,mte=on unconditionally for both KVM and TCG guests when MTE support is requested, or will that not work for the former? > +If not specified explicitly via ``on`` or ``off``, MTE will be available > +according to the following rules: > + > +* When TCG is used, MTE will be available if and only if tag memory is available; > + i.e. it preserves the behaviour prior to the introduction of the feature. > + > +* When KVM is used, MTE will default to off, so that migration will not > + unintentionally be blocked. This might change in a future QEMU version. If and when this changes, we should ensure that the new default behavior doesn't affect existing machine types, otherwise we will break guest ABI for existing VMs. -- Andrea Bolognani / Red Hat / Virtualization
