[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200624093846.GA11863@gaia>
Date: Wed, 24 Jun 2020 10:38:48 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Peter Maydell <peter.maydell@...aro.org>
Cc: Steven Price <steven.price@....com>, Marc Zyngier <maz@...nel.org>,
Will Deacon <will@...nel.org>,
Dave Martin <Dave.Martin@....com>,
lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
kvmarm@...ts.cs.columbia.edu,
arm-mail-list <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH 0/2] MTE support for KVM guest
On Tue, Jun 23, 2020 at 07:05:07PM +0100, Peter Maydell wrote:
> On Wed, 17 Jun 2020 at 13:39, Steven Price <steven.price@....com> wrote:
> > These patches add support to KVM to enable MTE within a guest. It is
> > based on Catalin's v4 MTE user space series[1].
> >
> > [1] http://lkml.kernel.org/r/20200515171612.1020-1-catalin.marinas%40arm.com
> >
> > Posting as an RFC as I'd like feedback on the approach taken.
>
> What's your plan for handling tags across VM migration?
> Will the kernel expose the tag ram to userspace so we
> can copy it from the source machine to the destination
> at the same time as we copy the actual ram contents ?
Qemu can map the guest memory with PROT_MTE and access the tags directly
with LDG/STG instructions. Steven was actually asking in the cover
letter whether we should require that the VMM maps the guest memory with
PROT_MTE as a guarantee that it can access the guest tags.
There is no architecturally visible tag ram (tag storage), that's a
microarchitecture detail.
--
Catalin
Powered by blists - more mailing lists