On Fri, Aug 11, 2023 at 05:26:24PM +0200, David Hildenbrand wrote:
I just started looking into the origins of "-mem-path".
Originally c902760fb2 ("Add option to use file backed guest memory"):
* Without MAP_POPULATE support, we use MAP_PRIVATE
* With MAP_POPULATE support we use MAP_PRIVATE if mem_prealloc was not
defined.
It was only used for hugetlb. The shared memory case didn't really matter:
they just needed a way to get hugetlb pages into the VM. Opening the file
R/W even with MAP_PRIVATE kind-of made sense in that case, it was an
exclusive owner.
Discarding of RAM was not very popular back then I guess: virtio-mem didn't
exist, virtio-balloon doesn't even handle hugetlb today really, postcopy
didn't exist.
I guess that's why nobody really cared about "-mem-path" MAP_PRIVATE vs.
MAP_SHARED semantics: just get hugetlb pages into the VM somehow.
Nowadays, "-mem-path" always defaults to MAP_PRIVATE. For the original
hugetlb use case, it's still good enough. For anything else, I'm not so
sure.
Ok this answers my other question then on the compat bit.. thanks. Feel
free to ignore there.
But then I'd lean back towards simply adding a fdperm=; that seems the
simplest, since even if with a compat bit, we still face risk of breaking
-mem-path users for anyone using new machine types.