On Mon, 2024-05-13 at 08:39 -0700, Sean Christopherson wrote: > > Sean, you mentioned that you envision guest_memfd also supporting non-CoCo VMs. > > Do you have some thoughts about how to make the above cases work in the > > guest_memfd context? > > Yes. The hand-wavy plan is to allow selectively mmap()ing guest_memfd(). There > is a long thread[*] discussing how exactly we want to do that. The TL;DR is that > the basic functionality is also straightforward; the bulk of the discussion is > around gup(), reclaim, page migration, etc. I still need to read this long thread, but just a thought on the word "restricted" here: for MMIO the instruction can be anywhere and similarly the load/store MMIO data can be anywhere. Does this mean that for running unmodified non-CoCo VMs with guest_memfd backend that we'll always need to have the whole of guest memory mmapped? I guess the idea is that this use case will still be subject to the normal restriction rules, but for a non-CoCo non-pKVM VM there will be no restriction in practice, and userspace will need to mmap everything always? It really seems yucky to need to have all of guest RAM mmapped all the time just for MMIO to work... But I suppose there is no way around that for Intel x86. JG > > [*] https://lore.kernel.org/all/ZdfoR3nCEP3HTtm1@xxxxxxxxxxxxxxxxxxxx
