Re: [PATCH Part2 RFC v4 07/40] x86/sev: Split the physmap when adding the page in RMP table
From: Brijesh Singh <hidden>
Date: 2021-07-15 17:06:02
Also in:
kvm, linux-coco, linux-efi, linux-mm, lkml, platform-driver-x86
On 7/14/21 5:25 PM, Sean Christopherson wrote:
quoted
A write from the hypervisor goes through the RMP checks. When the hypervisor writes to pages, hardware checks to ensures that the assigned bit in the RMP is zero (i.e page is shared). If the page table entry that gives the sPA indicates that the target page size is a large page, then all RMP entries for the 4KB constituting pages of the target must have the assigned bit 0. If one of entry does not have assigned bit 0 then hardware will raise an RMP violation. To resolve it, split the page table entry leading to target page into 4K.Isn't the above just saying: All RMP entries covered by a large page must match the shared vs. encrypted state of the page, e.g. host large pages must have assigned=0 for all relevant RMP entries.
Yes.
quoted
@@ -2375,6 +2375,12 @@ int rmpupdate(struct page *page, struct rmpupdate *val) if (!cpu_feature_enabled(X86_FEATURE_SEV_SNP)) return -ENXIO; + ret = set_memory_4k((unsigned long)page_to_virt(page), 1);IIUC, this shatters the direct map for page that's assigned to an SNP guest, and the large pages are never recovered? I believe a better approach would be to do something similar to memfd_secret[*], which encountered a similar problem with the direct map. Instead of forcing the direct map to be forever 4k, unmap the direct map when making a page guest private, and restore the direct map when it's made shared (or freed). I thought memfd_secret had also solved the problem of restoring large pages in the direct map, but at a glance I can't tell if that's actually implemented anywhere. But, even if it's not currently implemented, I think it makes sense to mimic the memfd_secret approach so that both features can benefit if large page preservation/restoration is ever added.
thanks for the memfd_secrets pointer. At the lowest level it shares the same logic to split the physmap. We both end up calling to change_page_attrs_set_clr() which split the page and updates the page table attributes. Given this, I believe in future if the change_page_attrs_set_clr() is enhanced to track the splitting of the pages and restore it later then it should work transparently. thanks