On 19/11/2020 15:45, Peter Maydell wrote:
On Thu, 19 Nov 2020 at 15:39, Steven Price <steven.price@xxxxxxx> wrote:
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-rc1, see [1] for an overview.
The change to require the VMM to map all guest memory PROT_MTE is
significant as it means that the VMM has to deal with the MTE tags even
if it doesn't care about them (e.g. for virtual devices or if the VMM
doesn't support migration). Also unfortunately because the VMM can
change the memory layout at any time the check for PROT_MTE/VM_MTE has
to be done very late (at the point of faulting pages into stage 2).
I'm a bit dubious about requring the VMM to map the guest memory
PROT_MTE unless somebody's done at least a sketch of the design
for how this would work on the QEMU side. Currently QEMU just
assumes the guest memory is guest memory and it can access it
without special precautions...
I agree this needs some investigation - I'm hoping Haibo will be able to
provide some feedback here as he has been looking at the QEMU support.
However the VMM is likely going to require some significant changes to
ensure that migration doesn't break, so either way there's work to be done.
Fundamentally most memory will need a mapping with PROT_MTE just so the
VMM can get at the tags for migration purposes, so QEMU is going to have
to learn how to treat guest memory specially if it wants to be able to
enable MTE for both itself and the guest.
I'll also hunt down what's happening with my attempts to fix the
set_pte_at() handling for swap and I'll post that as an alternative if
it turns out to be a reasonable approach. But I don't think that solve
the QEMU issue above.
The other alternative would be to implement a new kernel interface to
fetch tags from the guest and not require the VMM to maintain a PROT_MTE
mapping. But we need some real feedback from someone familiar with QEMU
to know what that interface should look like. So I'm holding off on that
until there's a 'real' PoC implementation.
Thanks,
Steve
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
