[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v6 4/8] KVM: Extend the memslot to support fd-based private m
From: |
Andy Lutomirski |
Subject: |
Re: [PATCH v6 4/8] KVM: Extend the memslot to support fd-based private memory |
Date: |
Sat, 21 May 2022 21:03:01 -0700 |
User-agent: |
Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27 |
On Fri, May 20, 2022, at 11:31 AM, Sean Christopherson wrote:
> But a dedicated KVM ioctl() to add/remove shared ranges would be easy
> to implement
> and wouldn't necessarily even need to interact with the memslots. It
> could be a
> consumer of memslots, e.g. if we wanted to disallow registering regions
> without an
> associated memslot, but I think we'd want to avoid even that because
> things will
> get messy during memslot updates, e.g. if dirty logging is toggled or a
> shared
> memory region is temporarily removed then we wouldn't want to destroy
> the tracking.
>
> I don't think we'd want to use a bitmap, e.g. for a well-behaved guest, XArray
> should be far more efficient.
>
> One benefit to explicitly tracking this in KVM is that it might be
> useful for
> software-only protected VMs, e.g. KVM could mark a region in the XArray
> as "pending"
> based on guest hypercalls to share/unshare memory, and then complete
> the transaction
> when userspace invokes the ioctl() to complete the share/unshare.
That makes sense.
If KVM goes this route, perhaps there the allowed states for a GPA should
include private, shared, and also private-and-shared. Then anyone who wanted
to use the same masked GPA for shared and private on TDX could do so if they
wanted to.
[PATCH v6 5/8] KVM: Add KVM_EXIT_MEMORY_FAULT exit, Chao Peng, 2022/05/19
[PATCH v6 6/8] KVM: Handle page fault for private memory, Chao Peng, 2022/05/19
[PATCH v6 7/8] KVM: Enable and expose KVM_MEM_PRIVATE, Chao Peng, 2022/05/19
[PATCH v6 8/8] memfd_create.2: Describe MFD_INACCESSIBLE flag, Chao Peng, 2022/05/19