On 20/03/2023 7:22 pm, Ковалёв Сергей wrote: > > 21.03.2023 1:51, Tamas K Lengyel wrote: >> On Mon, Mar 20, 2023 at 12:32 PM Ковалёв Сергей <[email protected] >> <mailto:[email protected]>> wrote: >> > >> > gva_to_gfn command used for fast address translation in LibVMI >> project. >> > With such a command it is possible to perform address translation in >> > single call instead of series of queries to get every page table. >> >> You have a couple assumptions here: >> - Xen will always have a direct map of the entire guest memory - >> there are already plans to move away from that. Without that this >> approach won't have any advantage over doing the same mapping by LibVMI > > Thanks! I didn't know about the plan.
To be clear, "not mapping the guest by default" is for speculative safety/hardening reasons. Xen will always need to be capable of mapping arbitrary parts of the guest, even if only transiently, so there's no relevant interaction with this new proposed hypercall. The truth is that Xen will always be able to do a single pagewalk faster than libvmi can do it (via mappings, or otherwise), but if libvmi does properly maintain a cache of mappings then it will be faster that repeated hypercalls into Xen. Where the split lies depends heavily on the libvmi workload. I don't see a problem in principle with a hypercall like this - it is "just" a performance optimisation over capabilities that libvmi already has - but the version presented here is overly simplistic. ~Andrew
