> In my proposal, I agree with you completely that the provider must be > allowed to revoke memory. Using the sample in this RFC, gmem_fd_ioctl() > called with !GMEM_PROVIDER_SET_PRESENT is where the provider wants to > revoke memory, and the revocation in my model would look like > > [PROVIDER] -> [GUEST_MEMFD] > > and [GUEST_MEMFD] would then fan it out to [KVM], [IOMMU], [USERSPACE] > and [DIRECTMAP].
(Fred is the one with his head in this space right now; I mostly wanted to get the ball rolling from our side. So if he contradicts me, take his word for it and don't necessarily wait for me to concede.) Your model above works for me, I think. I just don't *like* it very much. I had a nice clean (in my head) model where the memory provider is the owner of that memory, responsible for who owns what and whether it's read-only/shared/private/revoked, and for persisting it across live update. Anyone who wants a piece of it can come and ask, and it interfaced directly to KVM, IOMMU and anything else. And it was then theoretically usable for other things, too. Fred has already been working on ways for a guest to donate memory to the host for caches to support more efficient nesting, for example, and that could have used a memory provider (which, on the back end, has had its pages donated from the guest). The model of pushing it all into gmemfd probably works... but kind of makes my skin itch in ways I can't fully express. It does absolutely need to support PFN-based operation though. And one of the main design points is that we want to support the memory provider being the *trusted* arbiter of who owns what. The provider will be the part that gets the most careful review, that some people will be suggesting that we write in Rust because it magically fixes all bugs. Where in some platforms we have EL2 literally *enforcing* the fact that a rogue Linux kernel *cannot* access the wrong guests' memory, the model we want to support here is the next best thing, where a small and trusted piece of code provides and revokes those PFNs. As long as that's preserved, I guess it's probably OK to push more of the coordination into gmemfd than I had originally imagined. > Does your provider need to know if some memory was transitioned between > shared/private states? The provider can be notified too, if > necessary. If not, then isn't guest_memfd doing all the coordination > better than going via the provider? I think it at least needs to know, doesn't it? If a guest page is being taken away (donated to another guest, or something like Fred's nested cache), then we do kind of have opinions on whether it's back in 'shared' mode or whether it's still allegedly private to the guest which claimed to donate it.
smime.p7s
Description: S/MIME cryptographic signature
