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

[John Ferlan]

On 09/11/2018 03:53 AM, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Sep 11, 2018 at 2:46 AM, John Ferlan <jferlan at redhat.com> 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.
> 
> hostmem-memfd is quite similar to hostmem-file. The main benefits are
> that it doesn't need to create filesystem files, and it also enforces
> sealing, providing a bit more safety.
> 

So I can modify the commit message to:

    qemu: Prefer using memfd for anonymous memory

    Add support and prefer usage of hostmem-memfd backing when the
    memory backing source is anonymous and the QEMU capabilities
    support it. The main benefits are that it doesn't need to create
    filesystem files, and it also enforces sealing, providing a bit
    more safety.

>> 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.
> 
> Yes it could be documented. But it's now an allocation decision that
> could evolve, or an implementation detail.
> 
> Would you like to see something like that?
> 
>         <dt><code>source</code></dt>
> -       <dd>In this attribute you can switch to file memorybacking or keep
> -         default anonymous.</dd>
> +       <dd>In this attribute you can switch to file memorybacking or
> +       keep default anonymous. <span class="since">Since 4.8.0</span>,
> +       when the memory is anonymous and the host supports it, libvirt
> +       will use a memfd memory backing, providing additional safety
> +       guarantees.
> +       </dd>
>         <dt><code>access</code></dt>
> 

I won't make changes to the docs to describe how things are working.
I'll defer to Michal's reasoning. It's why I ask though especially in
areas where I have less exposure.

> 
>>

[...]

>> Running syntax-check would fail here because of the { }
>>
>> All this is fix-able without you needing to post another series, but I
>> need you to provide the verbiage for the intro and perhaps something
>> that could be added to the web page. I can adjust the patch accordingly.
>>
>> Assuming of course Michal doesn't have other reservations...
>>
>> Reviewed-by: John Ferlan <jferlan at redhat.com>
> 
> If you already resolved patch 1 & 2 conflicts, I would appreciate if
> you could take care. Otherwise I'll have to rebase & resend the
> patches.
> 
> thanks

I don't mind making the changes; however, based on the continued
migration discussion and possible need for more libvirt changes, I can
also hold off.

I could push the adjustments for patches 1 and 2, since they're
essentially ready. That may rankle a few feathers, but so does making
changes to the capabilities when there's already patches on list that
will be impacted by the pushed changes. I also don't think at this point
it's a question of "if" support for -memfd will be added, but "when". I
also assume the migration questions can be worked out.

Since this change would affect a 'default rule' for putting together the
backing store, I think perhaps we could modify the existing helper
qemuDomainABIStabilityCheck in order to make some "similar" or "sort of"
checks about the existing and future assumption. I think that'll solve
the "issue" at least from the POV of what QEMU will allow.

John

[...]