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

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.

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