On Mon, Jul 11 2022, "Dr. David Alan Gilbert" <dgilbert@xxxxxxxxxx> wrote: > * Cornelia Huck (cohuck@xxxxxxxxxx) 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@xxxxxxxxxx/ hooked itself directly into common code; maybe we should rather copy the approach used for s390 storage keys (extra "device") instead?
