qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 1/2] arm/kvm: add support for MTE


From: Peter Maydell
Subject: Re: [PATCH v4 1/2] arm/kvm: add support for MTE
Date: Tue, 17 Jan 2023 17:01:26 +0000

On Tue, 17 Jan 2023 at 16:51, Dr. David Alan Gilbert
<dgilbert@redhat.com> wrote:
>
> * Peter Maydell (peter.maydell@linaro.org) wrote:
> > On Wed, 11 Jan 2023 at 16:13, Cornelia Huck <cohuck@redhat.com> 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').

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]