[libvirt] Designing NVDIMM & memory-backend-file

[Daniel P. Berrange]

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 :|