On 04/12/2020 08:25, Haibo Xu wrote:
On Fri, 20 Nov 2020 at 17:51, Steven Price <steven.price@xxxxxxx> wrote:
On 19/11/2020 19:11, Marc Zyngier wrote:
On 2020-11-19 18:42, Andrew Jones wrote:
On Thu, Nov 19, 2020 at 03:45:40PM +0000, 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...
There are two statements being made here:
1) Requiring the use of PROT_MTE when mapping guest memory may not fit
QEMU well.
2) New KVM features should be accompanied with supporting QEMU code in
order to prove that the APIs make sense.
I strongly agree with (2). While kvmtool supports some quick testing, it
doesn't support migration. We must test all new features with a migration
supporting VMM.
I'm not sure about (1). I don't feel like it should be a major problem,
but (2).
(1) seems to be contentious whichever way we go. Either PROT_MTE isn't
required in which case it's easy to accidentally screw up migration, or
it is required in which case it's difficult to handle normal guest
memory from the VMM. I get the impression that probably I should go back
to the previous approach - sorry for the distraction with this change.
(2) isn't something I'm trying to skip, but I'm limited in what I can do
myself so would appreciate help here. Haibo is looking into this.
Hi Steven,
Sorry for the later reply!
I have finished the POC for the MTE migration support with the assumption
that all the memory is mapped with PROT_MTE. But I got stuck in the test
with a FVP setup. Previously, I successfully compiled a test case to verify
the basic function of MTE in a guest. But these days, the re-compiled test
can't be executed by the guest(very weird). The short plan to verify
the migration
is to set the MTE tags on one page in the guest, and try to dump the migrated
memory contents.
Hi Haibo,
Sounds like you are making good progress - thanks for the update. Have
you thought about how the PROT_MTE mappings might work if QEMU itself
were to use MTE? My worry is that we end up with MTE in a guest
preventing QEMU from using MTE itself (because of the PROT_MTE
mappings). I'm hoping QEMU can wrap its use of guest memory in a
sequence which disables tag checking (something similar will be needed
for the "protected VM" use case anyway), but this isn't something I've
looked into.
I will update the status later next week!
Great, I look forward to hearing how it goes.
Thanks,
Steve
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
