From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Thomas Huth <thuth@redhat.com>,
Laurent Vivier <lvivier@redhat.com>,
Eric Auger <eauger@redhat.com>,
Juan Quintela <quintela@redhat.com>,
qemu-arm@nongnu.org, qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [PATCH RFC v2 0/2] arm: enable MTE for QEMU + kvm
Date: Mon, 11 Jul 2022 14:24:05 +0100 [thread overview]
Message-ID: <YswkdVeESqf5sknQ@work-vm> (raw)
In-Reply-To: <20220707161656.41664-1-cohuck@redhat.com>
* Cornelia Huck (cohuck@redhat.com) wrote:
> This series makes it possible to enable MTE for kvm guests, if the kernel
> supports it. Again, tested on the simulator via patiently waiting for the
> arm64/mte kselftests to finish successfully.
>
> For tcg, turning on mte on the machine level (to get tag memory) stays a
> requirement. If the new mte cpu feature is not explicitly specified, a tcg
> vm will get mte depending on the presence of tag memory (just as today).
>
> For kvm, mte stays off by default; this is because migration is not yet
> supported (postcopy will need an extension of the kernel interface, possibly
> an extension of the userfaultfd interface), and turning on mte will add a
> migration blocker.
My assumption was that a normal migration would need something as well
to retrieve and place the MTE flags; albeit not atomically.
> My biggest question going forward is actually concerning migration; I gather
> that we should not bother adding something unless postcopy is working as well?
I don't think that restriction is fair on you; just make sure
postcopy_ram_supported_by_host gains an arch call and fails cleanly;
that way if anyone tries to enable postcopy they'll find out with a
clean fail.
> If I'm not misunderstanding things, we need a way to fault in a page together
> with the tag; doing that in one go is probably the only way that we can be
> sure that this is race-free on the QEMU side. Comments welcome :)
I think it will.
But, ignoring postcopy for a minute, with KVM how do different types of
backing memory work - e.g. if I back a region of guest memory with
/dev/shm/something or a hugepage equivalent, where does the MTE memory
come from, and how do you set it?
Dave
> Changes v1->v2: [Thanks to Eric for the feedback!]
> - add documentation
> - switch the mte prop to OnOffAuto; this improves the interaction with the
> existing mte machine prop
> - leave mte off for kvm by default
> - improve tests; the poking in QDicts feels a bit ugly, but seems to work
>
> Cornelia Huck (2):
> arm/kvm: add support for MTE
> qtests/arm: add some mte tests
>
> docs/system/arm/cpu-features.rst | 21 +++++
> target/arm/cpu.c | 18 ++---
> target/arm/cpu.h | 1 +
> target/arm/cpu64.c | 132 +++++++++++++++++++++++++++++++
> target/arm/internals.h | 1 +
> target/arm/kvm64.c | 5 ++
> target/arm/kvm_arm.h | 12 +++
> target/arm/monitor.c | 1 +
> tests/qtest/arm-cpu-features.c | 77 ++++++++++++++++++
> 9 files changed, 256 insertions(+), 12 deletions(-)
>
> --
> 2.35.3
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2022-07-11 13:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-07 16:16 [PATCH RFC v2 0/2] arm: enable MTE for QEMU + kvm Cornelia Huck
2022-07-07 16:16 ` [PATCH RFC v2 1/2] arm/kvm: add support for MTE Cornelia Huck
2022-07-07 16:16 ` [PATCH RFC v2 2/2] qtests/arm: add some mte tests Cornelia Huck
2022-07-09 2:59 ` [PATCH RFC v2 0/2] arm: enable MTE for QEMU + kvm Richard Henderson
2022-07-11 13:24 ` Dr. David Alan Gilbert [this message]
2022-07-11 13:39 ` Peter Maydell
2022-07-11 14:26 ` Dr. David Alan Gilbert
2022-07-11 14:56 ` Cornelia Huck
2022-07-11 15:30 ` Dr. David Alan Gilbert
2022-07-11 13:55 ` Dr. David Alan Gilbert
2022-07-11 15:08 ` Cornelia Huck
2022-07-11 15:28 ` Dr. David Alan Gilbert
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=YswkdVeESqf5sknQ@work-vm \
--to=dgilbert@redhat.com \
--cc=cohuck@redhat.com \
--cc=eauger@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=lvivier@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.