* Peter Maydell (peter.maydell@xxxxxxxxxx) wrote: > On Tue, 17 Jan 2023 at 16:51, Dr. David Alan Gilbert > <dgilbert@xxxxxxxxxx> wrote: > > > > * Peter Maydell (peter.maydell@xxxxxxxxxx) wrote: > > > On Wed, 11 Jan 2023 at 16:13, Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > > > > +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. > > > > + > > > > +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 iff tag memory is available; i.e. it > > > > + preserves the behaviour prior to introduction of the feature. > > > > + > > > > +* When KVM is used, MTE will default to off, so that migration will not > > > > + unintentionally be blocked. > > > > + > > > > +* Other accelerators currently don't support MTE. > > > > > > Minor nits for the documentation: > > > we should expand out "if and only if" -- not everybody recognizes > > > "iff", especially if they're not native English speakers or not > > > mathematicians. > > > > > > Should we write specifically that in a future QEMU version KVM > > > might change to defaulting to "on if available" when migration > > > support is implemented? > > > > Please make sure if you do something like that, that the failure > > is obious; 'on if available' gets messy for things like libvirt > > and higher level tools detecting features that are available and > > machines they can migrate to. > > If we have a plan for how this ought to work when we eventually > implement migration support that's great and we should document > it. My point is really "we should make sure we don't box ourselves > into a set of defaults that we regret in the future, eg where > TCG and KVM always have different defaults forever". If we don't > have a plan for what the future is, then I'd rather we delayed > adding MTE-without-migration-support until we've determined that > plan. > > Though the default for the CPU property is a bit moot, because > at the machine level we only implement tag memory on the virt > board, and there we disable it at the machine level (ie the > machine property 'mte' defaults to 'false'). Oh, if you're disabling it at the machine level that's fine; with versioned machine types the answer then is to turn it on at the machine level when it all works, and that keeps the old machine types with it off, and then VMs migrating with the old machine type don't get confused. (Having said that, there are always odd rules around CPU flags and machine types and what libvirt thinks of them, but I'd ask a libvirt person (jdenemar) for more details if needed). Dave > thanks > -- PMM > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
