On 01.07.2016 17:06, Daniel P. Berrange wrote:
On Fri, Jul 01, 2016 at 04:35:18PM +0200, Michal Privoznik wrote:
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:-)
I'm not really a fan of exposing file paths for shm in the XML. This filesystem exposure of shm is a linux specific concept which other UNIX with shm support don't do afaik. This is the same reasn why we don't expose the actual hugepages path in the XML, just let the user request hugepages and libvirt figures out the linux-specific way to enable it.
Okay, fair enough. And I can see it working with /dev/shm. But for NVDIMM we certainly have to let users specify path to the DIMM module. Therefore I suggested what I've suggested. But maybe I'm joining two separate problems together. So for the /dev/shm part there seems to be some movement. But for the NVDIMM module - any ideas how to express that one? Michal