On Sat, 20 Jul 2024 16:28:25 -0400 Steven Sistare <steven.sist...@oracle.com> wrote:
> On 7/16/2024 5:19 AM, Igor Mammedov wrote: > > On Sun, 30 Jun 2024 12:40:24 -0700 > > Steve Sistare <steven.sist...@oracle.com> wrote: > > > >> Allocate anonymous memory using mmap MAP_ANON or memfd_create depending > >> on the value of the anon-alloc machine property. This affects > >> memory-backend-ram objects, guest RAM created with the global -m option > >> but without an associated memory-backend object and without the -mem-path > >> option > > nowadays, all machines were converted to use memory backend for VM RAM. > > so -m option implicitly creates memory-backend object, > > which will be either MEMORY_BACKEND_FILE if -mem-path present > > or MEMORY_BACKEND_RAM otherwise. > > Yes. I dropped an an important adjective, "implicit". > > "guest RAM created with the global -m option but without an explicit > associated > memory-backend object and without the -mem-path option" > > >> To access the same memory in the old and new QEMU processes, the memory > >> must be mapped shared. Therefore, the implementation always sets > > > >> RAM_SHARED if alloc-anon=memfd, except for memory-backend-ram, where the > >> user must explicitly specify the share option. In lieu of defining a new > > so statement at the top that memory-backend-ram is affected is not > > really valid? > > memory-backend-ram is affected by alloc-anon. But in addition, the user must > explicitly add the "share" option. I don't implicitly set share in this case, > because I would be overriding the user's specification of the memory object's > property, > which would be private if omitted. instead of touching implicit RAM (-m), it would be better to error out and ask user to provide properly configured memory-backend explicitly. > > >> RAM flag, at the lowest level the implementation uses RAM_SHARED with fd=-1 > >> as the condition for calling memfd_create. > > > > In general I do dislike adding yet another option that will affect > > guest RAM allocation (memory-backends should be sufficient). > > > > However I do see that you need memfd for device memory (vram, roms, ...). > > Can we just use memfd/shared unconditionally for those and > > avoid introducing a new confusing option? > > The Linux kernel has different tunables for backing memfd's with huge pages, > so we > could hurt performance if we unconditionally change to memfd. The user > should have > a choice for any segment that is large enough for huge pages to improve > performance, > which potentially is any memory-backend-object. The non memory-backend > objects are > small, and it would be OK to use memfd unconditionally for them. > > - Steve >
