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(-)
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. [1] https://lwn.net/Articles/834289/ Changes since v5[2]: * Revert back to not requiring the VMM to map all guest memory PROT_MTE. Instead KVM will set the PG_mte_tagged flag automatically if not present. * Fixed swap behaviour vs v4 by always checking for saved MTE tags for user entries in set_pte_at(). [2] https://lore.kernel.org/r/20201119153901.53705-1-steven.price%40arm.com Steven Price (2): arm64: kvm: Save/restore MTE registers arm64: kvm: Introduce MTE VCPU feature 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(-) -- 2.20.1
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. Given that MTE-capable HW does that unconditionally, this is going to be a mess for big.LITTLE. :/ Thanks, Mark.
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; > 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. Thanks, Steve
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.
© 2016 - 2024 Red Hat, Inc.