[libvirt] Designing NVDIMM & memory-backend-file
Michal Privoznik
mprivozn at redhat.com
Mon Jul 4 09:21:20 UTC 2016
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
More information about the libvir-list
mailing list