From: Cornelia Huck <cohuck@redhat.com>
To: Andrea Bolognani <abologna@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
"Laurent Vivier" <lvivier@redhat.com>,
qemu-arm@nongnu.org, qemu-devel@nongnu.org, kvm@vger.kernel.org,
"Eric Auger" <eauger@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Juan Quintela" <quintela@redhat.com>,
"Gavin Shan" <gshan@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>
Subject: Re: [PATCH v6 1/2] arm/kvm: add support for MTE
Date: Wed, 01 Mar 2023 15:15:17 +0100 [thread overview]
Message-ID: <87sfeoblsa.fsf@redhat.com> (raw)
In-Reply-To: <CABJz62MQH2U1QM26PcC3F1cy7t=53_mxkgViLKjcUMVmi29w+Q@mail.gmail.com>
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.
We might want to tweak the documentation for the machine property to
indicate that it creates tag memory and only implicitly enables mte but
is a pre-req for it -- thoughts?
>
> From the libvirt integration point of view, setting the machine type
> property only for TCG is not a problem.
Ok.
next prev parent reply other threads:[~2023-03-01 14:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-28 15:02 [PATCH v6 0/2] arm: enable MTE for QEMU + kvm Cornelia Huck
2023-02-28 15:02 ` [PATCH v6 1/2] arm/kvm: add support for MTE Cornelia Huck
2023-02-28 17:34 ` Andrea Bolognani
2023-03-01 10:17 ` Cornelia Huck
2023-03-01 13:51 ` Andrea Bolognani
2023-03-01 14:15 ` Cornelia Huck [this message]
2023-03-01 14:54 ` Andrea Bolognani
2023-03-02 13:26 ` Cornelia Huck
2023-03-02 13:39 ` Andrea Bolognani
2023-03-02 13:46 ` Peter Maydell
2023-03-02 14:28 ` Cornelia Huck
2023-03-02 16:00 ` Peter Maydell
2023-03-03 16:30 ` Cornelia Huck
2023-03-07 17:05 ` Cornelia Huck
2023-03-03 16:11 ` Peter Maydell
2023-03-03 16:18 ` Cornelia Huck
2023-02-28 15:02 ` [PATCH v6 2/2] qtests/arm: add some mte tests Cornelia Huck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sfeoblsa.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=abologna@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eauger@redhat.com \
--cc=gshan@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=lvivier@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).