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