On Thursday 29 Feb 2024 at 11:04:09 (+0100), David Hildenbrand wrote: > An alternative would be to remember in pKVM that a page needs a wipe before > reaccess. Once re-accessed by anybody (hypervisor or new guest), it first > has to be wiped by pKVM. > > ... but that also sounds complicated and similar requires the linear > map+unmap in pKVM page-by-page as they are reused. But at least a guest > shutdown would be faster. Yep, FWIW we did try that, but ended up having issues with Linux trying to DMA to these pages before 'touching' them from the CPU side. pKVM can keep the pages unmapped from the CPU and IOMMU stage-2 page-tables, and we can easily handle the CPU faults lazily, but not faults from other masters, our hardware generally doesn't support that. <snip> > As discussed in the sub-thread, that might still be required. > > One could think about completely forbidding GUP on these mmap'ed > guest-memfds. But likely, there might be use cases in the future where you > want to use GUP on shared memory inside a guest_memfd. > > (the iouring example I gave might currently not work because > FOLL_PIN|FOLL_LONGTERM|FOLL_WRITE only works on shmem+hugetlb, and > guest_memfd will likely not be detected as shmem; 8ac268436e6d contains some > details) Perhaps it would be wise to start with GUP being forbidden if the current users do not need it (not sure if that is the case in Android, I'll check) ? We can always relax this constraint later when/if the use-cases arise, which is obviously much harder to do the other way around. Thanks, Quentin
