[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 16:28:07 +0100 |
User-agent: |
Mutt/2.2.6 (2022-06-05) |
* Cornelia Huck (cohuck@redhat.com) wrote:
> On Mon, Jul 11 2022, "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
>
> > * Cornelia Huck (cohuck@redhat.com) wrote:
> >> 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.
>
> There's KVM_ARM_MTE_COPY_TAGS, which should be sufficient to move tags
> around for normal migration.
>
> >
> >> 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.
>
> Ok, if simply fencing off postcopy is fine, we can try to move forward
> with what we have now. The original attempt at
> https://lore.kernel.org/all/881871e8394fa18a656dfb105d42e6099335c721.1615972140.git.haibo.xu@linaro.org/
> hooked itself directly into common code; maybe we should rather copy the
> approach used for s390 storage keys (extra "device") instead?
I don't understand how a separate device would keep the idea of page
changed flags coherent with the main RAM that the tags correspond to.
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK