Re: [PATCH v6 0/2] MTE support for KVM guest

Mark Rutland
2020-12-03T16:59:50Z

On Thu, Dec 03, 2020 at 04:49:49PM +0000, Steven Price wrote:
> On 03/12/2020 16:09, Mark Rutland wrote:
> > On Fri, Nov 27, 2020 at 03:21:11PM +0000, Steven Price wrote:
> > > It's been a week, and I think the comments on v5 made it clear that
> > > enforcing PROT_MTE requirements on the VMM was probably the wrong
> > > approach. So since I've got swap working correctly without that I
> > > thought I'd post a v6 which hopefully addresses all the comments so far.
> > >
> > > This series adds support for Arm's Memory Tagging Extension (MTE) to
> > > KVM, allowing KVM guests to make use of it. This builds on the existing
> > > user space support already in v5.10-rc4, see [1] for an overview.
> >
> > > arch/arm64/include/asm/kvm_emulate.h | 3 +++
> > > arch/arm64/include/asm/kvm_host.h | 8 ++++++++
> > > arch/arm64/include/asm/pgtable.h | 2 +-
> > > arch/arm64/include/asm/sysreg.h | 3 ++-
> > > arch/arm64/kernel/mte.c | 18 +++++++++++++-----
> > > arch/arm64/kvm/arm.c | 9 +++++++++
> > > arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 14 ++++++++++++++
> > > arch/arm64/kvm/mmu.c | 16 ++++++++++++++++
> > > arch/arm64/kvm/sys_regs.c | 20 +++++++++++++++-----
> > > include/uapi/linux/kvm.h | 1 +
> > > 10 files changed, 82 insertions(+), 12 deletions(-)
> >
> > I note that doesn't fixup arch/arm64/kvm/inject_fault.c, where in
> > enter_exception64() we have:
> >
> > | // TODO: TCO (if/when ARMv8.5-MemTag is exposed to guests)
> >
> > ... and IIUC when MTE is present, TCO should be set when delivering an
> > exception, so I believe that needs to be updated to set TCO.
>
> Well spotted! As you say TCO should be set when delivering an exception, so
> we need the following:
>
> - // TODO: TCO (if/when ARMv8.5-MemTag is exposed to guests)
> + if (kvm_has_mte(vcpu->kvm))
> + new |= PSR_TCO_BIT;

Something of that sort, yes.

It'd be worth a look for any mention of TCO or MTE in case there are
other bits that need a fixup.

> > Given that MTE-capable HW does that unconditionally, this is going to be
> > a mess for big.LITTLE. :/
>
> I'm not sure I follow. Either all CPUs support MTE in which this isn't a
> problem, or the MTE feature just isn't exposed. We don't support a mix of
> MTE and non-MTE CPUs. There are several aspects of MTE which effective mean
> it's an all-or-nothing feature for the system.

So long as the host requires uniform MTE support, I agree that's not a
problem.

The fun is that the CPUs themselves will set TCO upon a real exception
regardless of whether the host is aware, and on a mismatched system some
CPUs will do that while others will not. In such a case the host and
guest will end up seeing the SPSR TCO bit set sometimes upon exceptions
from EL1 or EL2, and I hope that MTE-unaware CPUs ignore the bit upon
ERET, or we're going to have significant problems.

Thanks,
Mark.