On Tue, 2024-12-10 at 15:25 +0100, David Hildenbrand wrote: > In this meeting we'll likely discuss: > * Patrick: KVM gmem MMIO access challenges and KVM_X86_SW_PROTECTED_VM > for arm > * Aneesh: Feasibility of 4 KiB guests on 64 KiB host > * Persisting guest_memfd across reboot / guest_memfs (if James is around) I should be around and will be keen to discuss this. Where we landed last on this topic was that guestmemfs should be modified to use the guest_memfd library code to instantiate a real guest_memfd file when a guestmemfs file is opened. Essentially the guestmemfs persistence will mostly be a custom allocator behind the in-development guest_memfd library code, including the ability to restore guest_memfd mappings when re-opening the file after kexec. The main dependency here is on the guest_memfd library effort. Discussion on how that's going and making sure that the guestmemfs persistence use case is covered will be useful. We need to make sure that the guest_memfd library supports: 1. Defining a custom allocator other than buddy-list managed pages so that a persistent reserved memory pool can be used. 2. Being able to re-drive or fault in mappings for a file after kexec. In all likelihood the allocator code path and equally restore previously allocated pages. 3. Support huge/gigantic mappings 4. Support mmaping the guest_memfd file; for non-CoCo VMs this will be necessary for PV devices. I realise that this is a whole can of worms currently under discussion and not specific to this use case. So, let's socialise this revised guestmemfs approach, and next steps for the library development. > > And we'll continue our discussion on: > * Challenges with supporting huge pages > * Challenges with shared vs. private conversion > * guest_memfd as a "library" JG Amazon Development Centre (South Africa) (Proprietary) Limited 29 Gogosoa Street, Observatory, Cape Town, Western Cape, 7925, South Africa Registration Number: 2004 / 034463 / 07
