From: Peter Maydell <peter.maydell@linaro.org>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: Juan Quintela <quintela@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Catalin Marinas <catalin.marinas@arm.com>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
Steven Price <steven.price@arm.com>,
arm-mail-list <linux-arm-kernel@lists.infradead.org>,
Marc Zyngier <maz@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>,
kvmarm <kvmarm@lists.cs.columbia.edu>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Dave Martin <Dave.Martin@arm.com>
Subject: Re: [PATCH v5 0/2] MTE support for KVM guest
Date: Wed, 9 Dec 2020 20:20:45 +0000 [thread overview]
Message-ID: <CAFEAcA_K47jKSp46DFK-AKWv6MD1pkrEB6FNz=HNGdxmBDCSbw@mail.gmail.com> (raw)
In-Reply-To: <6b9072fb-1232-e9fb-0b97-e69709980f99@linaro.org>
On Wed, 9 Dec 2020 at 20:13, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 12/9/20 12:39 PM, Catalin Marinas wrote:
> >> I would have thought that the best way is to use TCO, so that we don't have to
> >> have dual mappings (and however many MB of extra page tables that might imply).
> >
> > The problem appears when the VMM wants to use MTE itself (e.g. linked
> > against an MTE-aware glibc), toggling TCO is no longer generic enough,
> > especially when it comes to device emulation.
>
> But we do know exactly when we're manipulating guest memory -- we have special
> routines for that.
Well, yes and no. It's not like every access to guest memory
is through a specific set of "load from guest"/"store from guest"
functions, and in some situations there's a "get a pointer to
guest RAM, keep using it over a long-ish sequence of QEMU code,
then be done with it" pattern. It's because it's not that trivial
to isolate when something is accessing guest RAM that I don't want
to just have it be mapped PROT_MTE into QEMU. I think we'd end
up spending a lot of time hunting down "whoops, turns out this
is accessing guest RAM and sometimes it trips over the tags in
a hard-to-debug way" bugs. I'd much rather the kernel just
provided us with an API for what we want, which is (1) the guest
RAM as just RAM with no tag checking and separately (2) some
mechanism yet-to-be-designed which lets us bulk copy a page's
worth of tags for migration.
thanks
-- PMM
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2020-12-09 20:21 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-19 15:38 [PATCH v5 0/2] MTE support for KVM guest Steven Price
2020-11-19 15:39 ` [PATCH v5 1/2] arm64: kvm: Save/restore MTE registers Steven Price
2020-11-19 15:39 ` [PATCH v5 2/2] arm64: kvm: Introduce MTE VCPU feature Steven Price
2020-11-19 15:45 ` [PATCH v5 0/2] MTE support for KVM guest Peter Maydell
2020-11-19 15:57 ` Steven Price
2020-11-19 16:39 ` Peter Maydell
2020-11-19 18:42 ` Andrew Jones
2020-11-19 19:11 ` Marc Zyngier
2020-11-20 9:50 ` Steven Price
2020-11-20 9:56 ` Marc Zyngier
2020-11-20 9:58 ` Steven Price
2020-12-04 8:25 ` Haibo Xu
2020-12-07 14:48 ` Steven Price
2020-12-07 15:27 ` Peter Maydell
2020-12-07 15:45 ` Steven Price
2020-12-07 16:05 ` Marc Zyngier
2020-12-07 16:34 ` Catalin Marinas
2020-12-07 19:03 ` Marc Zyngier
2020-12-08 17:21 ` Catalin Marinas
2020-12-08 18:21 ` Marc Zyngier
2020-12-09 12:44 ` Catalin Marinas
2020-12-09 13:25 ` Marc Zyngier
2020-12-09 15:27 ` Catalin Marinas
2020-12-09 18:27 ` Richard Henderson
2020-12-09 18:39 ` Catalin Marinas
2020-12-09 20:13 ` Richard Henderson
2020-12-09 20:20 ` Peter Maydell [this message]
2020-12-07 16:44 ` Dr. David Alan Gilbert
2020-12-07 17:10 ` Peter Maydell
2020-12-07 17:44 ` Dr. David Alan Gilbert
2020-12-08 10:05 ` Haibo Xu
2020-12-08 9:51 ` Haibo Xu
2020-12-08 10:01 ` Marc Zyngier
2020-12-08 10:10 ` Haibo Xu
2020-12-16 7:31 ` Haibo Xu
2020-12-16 10:22 ` Steven Price
2020-12-17 1:47 ` Haibo Xu
2020-11-23 12:16 ` 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='CAFEAcA_K47jKSp46DFK-AKWv6MD1pkrEB6FNz=HNGdxmBDCSbw@mail.gmail.com' \
--to=peter.maydell@linaro.org \
--cc=Dave.Martin@arm.com \
--cc=catalin.marinas@arm.com \
--cc=dgilbert@redhat.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=richard.henderson@linaro.org \
--cc=steven.price@arm.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
/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).