On 10.07.24 23:53, Sean Christopherson wrote:
On Wed, Jul 10, 2024, David Hildenbrand wrote:
On 10.07.24 11:51, Patrick Roy wrote:
On 7/9/24 22:13, David Hildenbrand wrote:
Note that just from staring at this commit, I don't understand the
motivation *why* we would want to do that.
Fair - I admittedly didn't get into that as much as I probably should
have. In our usecase, we do not have anything that pKVM would (I think)
call "guest-private" memory. I think our memory can be better described
as guest-owned, but always shared with the VMM (e.g. userspace), but
ideally never shared with the host kernel. This model lets us do a lot
of simplifying assumptions: Things like I/O can be handled in userspace
without the guest explicitly sharing I/O buffers (which is not exactly
what we would want long-term anyway, as sharing in the guest_memfd
context means sharing with the host kernel), we can easily do VM
snapshotting without needing things like TDX's TDH.EXPORT.MEM APIs, etc.
Okay, so essentially you would want to use guest_memfd to only contain shard
memory and disallow any pinning like for secretmem.
If so, I wonder if it wouldn't be better to simply add KVM support to
consume *real* secretmem memory? IIRC so far there was only demand to
probably remove the directmap of private memory in guest_memfd, not of
shared memory.
It's also desirable to remove shared memory from the directmap, e.g. to prevent
using the directmap in a cross-VM attack.
I don't think we want to allow KVM to consume secretmem. That would require
letting KVM gup() secretmem, which AIUI defeats the entire purpose of secretmem,
and I don't think KVM should be special.
I would mean consuming secretmem via the fd, *not* via page tables / gup.
But if we also want to have the option of directmap modifications for
shared memory in guest_memfd, we could make that indeed a guest_memfd
feature.
--
Cheers,
David / dhildenb
