Re: [RFC PATCH 0/9] mm: Memory providers for guest_memfd and iommufd

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2807 bytes --]

> 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.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6179 bytes --]