lkml.org 
[lkml]   [2021]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] KVM: mm: fd-based approach for supporting KVM guest private memory
From
Date
>>
>> In principle, you could actually initialize a TDX guest with all of its
>> memory shared and all of it mapped in the host IOMMU. When a guest
>> turns some pages private, user code could punch a hole in the memslot,
>> allocate private memory at that address, but leave the shared backing
>> store in place and still mapped in the host IOMMU. The result would be
>> that guest-initiated DMA to the previously shared address would actually
>> work but would hit pages that are invisible to the guest. And a whole
>> bunch of memory would be waste, but the whole system should stll work.
>
> Do you mean to let VFIO & IOMMU to treat all guest memory as shared first,
> and then just allocate the private pages in another backing store? I guess
> that could work, but with the cost of allocating roughly 2x physical pages
> of the guest RAM size. After all, the shared pages shall be only a small
> part of guest memory.

Yes.

My point is that I don't think there should be any particular danger in
leaving the VFIO code alone as part of TDX enablement. The code ought
to *work* even if it will be wildly inefficient. If someone cares to
make it work better, they're welcome to do so.

--Andy

\
 
 \ /
  Last update: 2021-09-02 20:42    [W:0.077 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site