[libvirt] Designing NVDIMM & memory-backend-file

[Michal Privoznik]

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