On Wed, 9 Dec 2020 at 20:13, Richard Henderson <richard.henderson@xxxxxxxxxx> wrote: > > On 12/9/20 12:39 PM, Catalin Marinas wrote: > >> I would have thought that the best way is to use TCO, so that we don't have to > >> have dual mappings (and however many MB of extra page tables that might imply). > > > > The problem appears when the VMM wants to use MTE itself (e.g. linked > > against an MTE-aware glibc), toggling TCO is no longer generic enough, > > especially when it comes to device emulation. > > But we do know exactly when we're manipulating guest memory -- we have special > routines for that. Well, yes and no. It's not like every access to guest memory is through a specific set of "load from guest"/"store from guest" functions, and in some situations there's a "get a pointer to guest RAM, keep using it over a long-ish sequence of QEMU code, then be done with it" pattern. It's because it's not that trivial to isolate when something is accessing guest RAM that I don't want to just have it be mapped PROT_MTE into QEMU. I think we'd end up spending a lot of time hunting down "whoops, turns out this is accessing guest RAM and sometimes it trips over the tags in a hard-to-debug way" bugs. I'd much rather the kernel just provided us with an API for what we want, which is (1) the guest RAM as just RAM with no tag checking and separately (2) some mechanism yet-to-be-designed which lets us bulk copy a page's worth of tags for migration. thanks -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
