qemu-devel
[Top][All Lists]
Advanced

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

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


From: Peter Maydell
Subject: Re: [PATCH v6 1/2] arm/kvm: add support for MTE
Date: Thu, 2 Mar 2023 13:46:21 +0000

On Wed, 1 Mar 2023 at 14:15, Cornelia Huck <cohuck@redhat.com> wrote:
>
> On Wed, Mar 01 2023, Andrea Bolognani <abologna@redhat.com> wrote:
>
> > On Wed, Mar 01, 2023 at 11:17:40AM +0100, Cornelia Huck wrote:
> >> On Tue, Feb 28 2023, Andrea Bolognani <abologna@redhat.com> wrote:
> >> > On Tue, Feb 28, 2023 at 04:02:15PM +0100, Cornelia Huck 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.
> >> >
> >> > 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?
> >>
> >> QEMU will error out if you try this with KVM (basically, same behaviour
> >> as before.) Is that a problem for libvirt, or merely a bit inconvinient?
> >
> > I'm actually a bit confused. The documentation for the mte property
> > of the virt machine type says
> >
> >   mte
> >     Set on/off to enable/disable emulating a guest CPU which implements
> >     the Arm Memory Tagging Extensions. The default is off.
> >
> > So why is there a need to have a CPU property in addition to the
> > existing machine type property?
>
> I think the state prior to my patches is actually a bit confusing: the
> user needs to set a machine type property (causing tag memory to be
> allocated), which in turn enables a cpu feature. Supporting the machine
> type property for KVM does not make much sense IMHO: we don't allocate
> tag memory for KVM (in fact, that would not work). We have to keep the
> previous behaviour, and explicitly instructing QEMU to create cpus with
> a certain feature via a cpu property makes the most sense to me.

This isn't really how the virt board does any other of these
properties, though: secure=on/off and virtualization=on/off also
both work by having a board property that sets up the board related
parts and also sets the CPU property appropriately.

I think having MTE in the specific case of KVM behave differently
to how we've done all these existing properties and how we've
done MTE for TCG would be confusing. The simplest thing is to just
follow the existing UI for TCG MTE.

The underlying reason for this is that MTE in general is not a feature
only of the CPU, but also of the whole system design. It happens
that KVM gives us tagged RAM "for free" but that's an oddity
of the KVM implementation -- in real hardware there needs to
be system level support for tagging.

thanks
-- PMM



reply via email to

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