[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC v2 0/2] arm: enable MTE for QEMU + kvm
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [PATCH RFC v2 0/2] arm: enable MTE for QEMU + kvm |
Date: |
Mon, 11 Jul 2022 14:55:13 +0100 |
User-agent: |
Mutt/2.2.6 (2022-06-05) |
* Dr. David Alan Gilbert (dgilbert@redhat.com) wrote:
> * Cornelia Huck (cohuck@redhat.com) wrote:
> > This series makes it possible to enable MTE for kvm guests, if the kernel
> > supports it. Again, tested on the simulator via patiently waiting for the
> > arm64/mte kselftests to finish successfully.
> >
> > For tcg, turning on mte on the machine level (to get tag memory) stays a
> > requirement. If the new mte cpu feature is not explicitly specified, a tcg
> > vm will get mte depending on the presence of tag memory (just as today).
> >
> > For kvm, mte stays off by default; this is because migration is not yet
> > supported (postcopy will need an extension of the kernel interface, possibly
> > an extension of the userfaultfd interface), and turning on mte will add a
> > migration blocker.
>
> My assumption was that a normal migration would need something as well
> to retrieve and place the MTE flags; albeit not atomically.
>
> > My biggest question going forward is actually concerning migration; I gather
> > that we should not bother adding something unless postcopy is working as
> > well?
>
> I don't think that restriction is fair on you; just make sure
> postcopy_ram_supported_by_host gains an arch call and fails cleanly;
> that way if anyone tries to enable postcopy they'll find out with a
> clean fail.
>
> > If I'm not misunderstanding things, we need a way to fault in a page
> > together
> > with the tag; doing that in one go is probably the only way that we can be
> > sure that this is race-free on the QEMU side. Comments welcome :)
>
> I think it will.
> But, ignoring postcopy for a minute, with KVM how do different types of
> backing memory work - e.g. if I back a region of guest memory with
> /dev/shm/something or a hugepage equivalent, where does the MTE memory
> come from, and how do you set it?
Another case that just came to mind, are the data content optimisations;
we special case all-zero pages, which I guess you still need to transmit
tags for, and the xbzrle page-difference code wouldn't notice
differences in tags.
Dave
> Dave
>
> > Changes v1->v2: [Thanks to Eric for the feedback!]
> > - add documentation
> > - switch the mte prop to OnOffAuto; this improves the interaction with the
> > existing mte machine prop
> > - leave mte off for kvm by default
> > - improve tests; the poking in QDicts feels a bit ugly, but seems to work
> >
> > Cornelia Huck (2):
> > arm/kvm: add support for MTE
> > qtests/arm: add some mte tests
> >
> > docs/system/arm/cpu-features.rst | 21 +++++
> > target/arm/cpu.c | 18 ++---
> > target/arm/cpu.h | 1 +
> > target/arm/cpu64.c | 132 +++++++++++++++++++++++++++++++
> > target/arm/internals.h | 1 +
> > target/arm/kvm64.c | 5 ++
> > target/arm/kvm_arm.h | 12 +++
> > target/arm/monitor.c | 1 +
> > tests/qtest/arm-cpu-features.c | 77 ++++++++++++++++++
> > 9 files changed, 256 insertions(+), 12 deletions(-)
> >
> > --
> > 2.35.3
> >
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK