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. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
