Re: [PATCH v7 00/14] KVM: mm: fd-based approach for supporting KVM guest private memory

[Nikunj A. Dadhania]

On 15/08/22 18:34, Chao Peng wrote:
> On Fri, Aug 12, 2022 at 02:18:43PM +0530, Nikunj A. Dadhania wrote:
>>
>>
>> On 12/08/22 12:48, Gupta, Pankaj wrote:
>>>
>>>>>>>>
>>>>>>>> However, fallocate() preallocates full guest memory before starting 
>>>>>>>> the guest.
>>>>>>>> With this behaviour guest memory is *not* demand pinned. Is there a 
>>>>>>>> way to
>>>>>>>> prevent fallocate() from reserving full guest memory?
>>>>>>>
>>>>>>> Isn't the pinning being handled by the corresponding host memory 
>>>>>>> backend with mmu > notifier and architecture support while doing the 
>>>>>>> memory operations e.g page> migration and swapping/reclaim (not 
>>>>>>> supported currently AFAIU). But yes, we need> to allocate entire guest 
>>>>>>> memory with the new flags MEMFILE_F_{UNMOVABLE, UNRECLAIMABLE etc}.
>>>>>>
>>>>>> That is correct, but the question is when does the memory allocated, as 
>>>>>> these flags are set,
>>>>>> memory is neither moved nor reclaimed. In current scenario, if I start a 
>>>>>> 32GB guest, all 32GB is
>>>>>> allocated.
>>>>>
>>>>> I guess so if guest memory is private by default.
>>>>>
>>>>> Other option would be to allocate memory as shared by default and
>>>>> handle on demand allocation and RMPUPDATE with page state change event. 
>>>>> But still that would be done at guest boot time, IIUC.
>>>>
>>>> Sorry! Don't want to hijack the other thread so replying here.
>>>>
>>>> I thought the question is for SEV SNP. For SEV, maybe the hypercall with 
>>>> the page state information can be used to allocate memory as we use it or 
>>>> something like quota based memory allocation (just thinking).
>>>
>>> But all this would have considerable performance overhead (if by default 
>>> memory is shared) and used mostly at boot time. 
>>
>>> So, preallocating memory (default memory private) seems better approach for 
>>> both SEV & SEV SNP with later page management (pinning, reclaim) taken care 
>>> by host memory backend & architecture together.
>>
>> I am not sure how will pre-allocating memory help, even if guest would not 
>> use full memory it will be pre-allocated. Which if I understand correctly is 
>> not expected.
> 
> Actually the current version allows you to delay the allocation to a
> later time (e.g. page fault time) if you don't call fallocate() on the
> private fd. fallocate() is necessary in previous versions because we
> treat the existense in the fd as 'private' but in this version we track
> private/shared info in KVM so we don't rely on that fact from memory
> backstores.

Thanks for confirming Chao, in that case we can drop fallocate() from qemu 
in both the case
* Once while creating the memfd private object
* During ram_block_convert_range() for shared->private and vice versa.
 
> Definitely the page will still be pinned once it's allocated, there is
> no way to swap it out for example just with the current code. 

Agree, at present once the page is brought in, page will remain till VM 
shutdown.

> That kind of support, if desirable, can be extended through MOVABLE flag and 
> some
> other callbacks to let feature-specific code to involve.

Sure, that could be future work.

Regards
Nikunj