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

[Michal Privoznik]

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?

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)?

Michal