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

[Dr. David Alan Gilbert]

* Marc-André Lureau (marcandre.lureau at redhat.com) wrote:
> Hi
> 
> On Tue, Sep 11, 2018 at 12:37 PM, Michal Privoznik <mprivozn at redhat.com> wrote:
> > On 09/11/2018 12:46 AM, John Ferlan wrote:
> >>
> >> On 09/07/2018 07:32 AM, marcandre.lureau at redhat.com wrote:
> >>> From: Marc-André Lureau <marcandre.lureau at redhat.com>
> >>>
> >>
> >> 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 at redhat.com / Manchester, UK