* Cornelia Huck (cohuck@xxxxxxxxxx) wrote: > 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? 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@xxxxxxxxxx / Manchester, UK
