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. It is ok to allow apps to request anonymous vs file backed memory as a general concept, but I don't think we should let them request specific paths with specific semantics. ie, with your suggestion here an app could request /dev/hugepages as the path and turn on huge pages for the guest via the back door I much prefer this proposed design to allow requesting file backed memory https://www.redhat.com/archives/libvir-list/2016-June/msg01651.html Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list