Re: [libvirt] [PATCH 3/5] qemu: prefer memfd for anonymous memory

* Marc-André Lureau (marcandre.lureau(a)redhat.com) wrote: > Hi > > On Tue, Sep 11, 2018 at 12:37 PM, Michal Privoznik <mprivozn(a)redhat.com&gt; wrote: > > On 09/11/2018 12:46 AM, John Ferlan wrote: > >> > >> On 09/07/2018 07:32 AM, marcandre.lureau(a)redhat.com wrote: > >>> From: Marc-André Lureau <marcandre.lureau(a)redhat.com&gt; > >>> > >> > >> Would be nice to have a few more words here. If you provide them I can > >> add them... The if statement is difficult to read unless you know what > >> each field really means. > >> > >> secondary question - should we document what gets used?, e.g.: > >> > >> https://libvirt.org/formatdomain.html#elementsMemoryBacking > >> > >> Seems to me the preference to use memfd is for memory backing using > >> anonymous source for nvdimm's without a defined path, but sometimes my > >> wording doesn't match reality. > > > > I don't think we want to tell users what backend are we going to use > > under what conditions. Firstly, these conditions will change (as they > > did in the past). Secondly, what backend libvirt decides to use is no > > business of users. I mean, they care about providing XML that matches > > their demands. It's libvirt's job to fulfil them. > > > > Look at this from the other way: if an user wants to have > > memory-backend-file for his domain, how would they enforce it once memfd > > is merged? Sure, they can tweak their memoryBacking settings, but that > > would work only until we decide to change the decision process for mem > > backend. > > > > What I am more worried about is migration. What happens if I migrate a > > hugepages domain from older libvirt to a newer one (the former doesn't > > support memfd, the latter does). On the source the domain was started > > with memory-backend-file (or memory-backend-ram with -mem-path). And > > during migration, the generated cmd line would use memfd. And I don't > > think qemu is capable of dealing with this discrepancy, is it? > > > Actually, qemu doesn't care about the hostmem backend kind, it should > handle the migration ok. > > However, there seems to be a bug in qemu, and hostmem backend don't > use the right qom object name. Can you give me the command lines you're using?

Dave > with memory-backend-ram: > > (qemu) info qom-tree /objects > /objects (container) > /mem (memory-backend-file) > /mem[0] (qemu:memory-region) > > But with memory-backend-file or memory-backend-memfd: > > (qemu) info qom-tree /objects > /objects (container) > /mem (memory-backend-file) > /\x2fobjects\x2fmem[0] (qemu:memory-region) > > > This causes migration to fail because of the object naming mismatch. > > It can migrate from/to -file and -memfd, since they use the same > "broken" name, but not with -ram. > > I don't know how we can solve this migration issue without breaking > things further. Any idea David? > > > Or is memfd going to be used only for hugepages + <source > > type='anonymous'/> case (which is not allowed now and thus migration > > scenario I'm describing can't happen)? > > With those patches, memfd is used for anonymous memory (shared or not, > hpt or not) with an explicit numa configuration. > > thanks -- Dr. David Alan Gilbert / dgilbert(a)redhat.com / Manchester, UK