> -----Original Message----- > From: Daniel P. Berrange [mailto:berrange@xxxxxxxxxx] > Sent: Monday, January 30, 2017 12:35 PM > To: Michal Privoznik <mprivozn@xxxxxxxxxx> > Cc: Safka, JaroslavX <jaroslavx.safka@xxxxxxxxx>; libvir-list@xxxxxxxxxx; > Mooney, Sean K <sean.k.mooney@xxxxxxxxx>; Ptacek, MichalX > <michalx.ptacek@xxxxxxxxx> > Subject: Re: [PATCHv4 0/3] Add support for file memorybacking > > On Sat, Jan 28, 2017 at 03:03:02PM +0100, Michal Privoznik wrote: > > On 13.12.2016 13:12, Jaroslav Safka wrote: > > > Hi, > > > we would like to introduce 3 new elements source,access and allocation in > memoryBacking element. > > > For now it was made for numa topology. > > > > > > <memoryBacking> > > > <source type="file|anonymous"/> > > > <access mode="shared|private"/> > > > <allocation mode="immediate|ondemand"/> </memoryBacking> > > > > > > If allocation is immediate then -mem-prealloc should be added to the qemu > commanline. > > > If source is file then > > > -object memory-backend-file,id=mem,size=1024M,mem-path=*lib dir > > > path* -numa node,memdev=mem Will be added to the qemu commandline > > > > > > If access is shared then the "share=on" parameter will be added to the > memory-backend-file e.g. > > > -object > > > memory-backend-file,id=mem,size=1024M,mem- > path=/var/lib/libvirt/qemu > > > ,share=on > > > > > > The access mode can be overriden by specifying token memAccess in numa > cell. > > > > > > The test cpu-numa-memshared was removed, because behaviour was > > > changed and is not needed anymore > > > > I beg to disagree. What if you don't have any <memoryBacking/>? > > > > I like these patches, but I'm not certainly sure about: > > a) domain XML (in the past we used to require an ACK on schema change > > from one of the Dans) > > What are you unsure about ? This XML is what I suggested in previous rounds > of discussion. > > > b) the location for qemu to create its mmaped files (patch 3/3). > > cfg->libDir looks very suspicious. > > Well we've got two possibilities - source=anonymous, should be using > /dev/shm, similar to how we do huge pages. For source=file, we need a real > filesystem. Something under /var/lib/libvirt is reasonable. > Perhaps a dedicated dir is needed ? eg /var/lib/libvirt/ram in order to provide a > point where the admin can mount a sufficiently large filesystem ? Or make it > configurable in /etc/libvirt/qemu.conf > [Jarek] It will be ok when I do something like libDir + "/ram". Or It should be configurable on compilation time? > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
