Re: [libvirt] Designing NVDIMM & memory-backend-file

Dear list, I'd like to fix the following bug [1]. Long story short, the only way how to have a domain use memory-backend-file object is to configure hugepages. Either for whole domain under <memoryBacking/> element, or in <memory/> device: <memoryBacking> <hugepages> <page size='2048' unit='KiB' nodeset='1'/> </hugepages> </memoryBacking> -object memory-backend-file,id=ram-node1,prealloc=yes,\ mem-path=/dev/hugepages2M/libvirt/qemu,size=1073741824,host-nodes=0-3,\ policy=bind \ -numa node,nodeid=1,cpus=1,memdev=ram-node1 \ <memory model='dimm'> <source> <nodemask>1-3</nodemask> <pagesize unit='KiB'>2048</pagesize> </source> <target> <size unit='KiB'>524287</size> <node>0</node> </target> </memory> -object memory-backend-file,id=memdimm1,prealloc=yes,\ mem-path=/dev/hugepages2M/libvirt/qemu,size=536870912,host-nodes=1-3,policy=bind \ -device pc-dimm,node=0,memdev=memdimm1,id=dimm1 \ Now, there's a request in the BZ to allow applications to use the memory-backend-file but let them use different backend, well different path for backing the memory, e.g. shm which is usually mounted at /dev/shm. And I'd like to consult my idea before I dig deep in the patches. My idea is to extend <memory/> device we have, more precisely <source/> element to allow something like this: <memory model='dimm'> <source> <path>/dev/shm</path> </source> <target/> </memory> This way we can allow users to pass an arbitrary path to the memory-backend-file. Also the amount of code needing change would be fairly small O:-)