On 26.11.24 17:04, Nikita Kalyazin wrote:
On 21/11/2024 16:46, Nikita Kalyazin wrote:
On 20/11/2024 18:29, David Hildenbrand wrote:
> Any clue how your new ioctl will interact with the WIP to have shared
> memory as part of guest_memfd? For example, could it be reasonable to
> "populate" the shared memory first (via VMA) and then convert that
> "allocated+filled" memory to private?
Patrick and I synced internally on this. What may actually work for
guest_memfd population is the following.
Non-CoCo use case:
- fallocate syscall to fill the page cache, no page content
initialisation (like it is now)
- pwrite syscall to initialise the content + mark up-to-date (mark
prepared), no specific preparation logic is required
The pwrite will have "once" semantics until a subsequent
fallocate(FALLOC_FL_PUNCH_HOLE), ie the next pwrite call will "see" the
page is already prepared and return EIO/ENOSPC or something.
I prototyped that to see if it was possible (and it was). Actually the
write syscall can also do the allocation part, so no prior fallocate
would be required.
Right
The only thing is there is a cap on how much IO can
be done in a single call (MAX_RW_COUNT) [1], but it doesn't look like a
significant problem. Does it sound like an acceptable solution?
Does sound quite clean to me. Of course, one thing to figure out is how
to enable this only for that special type of VM type, but that should be
possible to be resolved.
--
Cheers,
David / dhildenb
