On 3/28/2024 8:02 AM, Isaku Yamahata wrote:
On Wed, Mar 27, 2024 at 09:49:14PM +0800,
Binbin Wu <binbin.wu@xxxxxxxxxxxxxxx> wrote:
On 3/15/2024 9:09 AM, Isaku Yamahata wrote:
Here is the updated one. Renamed dummy -> mirroed.
When KVM resolves the KVM page fault, it walks the page tables. To reuse
the existing KVM MMU code and mitigate the heavy cost of directly walking
the private page table, allocate one more page to copy the mirrored page
Here "copy" is a bit confusing for me.
The mirrored page table is maintained by KVM, not copied from anywhere.
How about, "maintain" or "keep"?
Or just use "for"?
i.e, allocate one more page for the mirrored page table ...
table for the KVM MMU code to directly walk. Resolve the KVM page fault
with the existing code, and do additional operations necessary for the
private page table. To distinguish such cases, the existing KVM page table
is called a shared page table (i.e., not associated with a private page
table), and the page table with a private page table is called a mirrored
page table. The relationship is depicted below.
KVM page fault |
| |
V |
-------------+---------- |
| | |
V V |
shared GPA private GPA |
| | |
V V |
shared PT root mirrored PT root | private PT root
| | | |
V V | V
shared PT mirrored PT ----propagate----> private PT
| | | |
| \-----------------+------\ |
| | | |
V | V V
shared guest page | private guest page
|
non-encrypted memory | encrypted memory
|
PT: Page table
Shared PT: visible to KVM, and the CPU uses it for shared mappings.
Private PT: the CPU uses it, but it is invisible to KVM. TDX module
updates this table to map private guest pages.
Mirrored PT: It is visible to KVM, but the CPU doesn't use it. KVM uses it
to propagate PT change to the actual private PT.
