summaryrefslogtreecommitdiff
path: root/Documentation/virt
diff options
context:
space:
mode:
authorPaolo Bonzini <pbonzini@redhat.com>2024-07-26 20:45:36 +0300
committerPaolo Bonzini <pbonzini@redhat.com>2024-07-26 21:46:15 +0300
commit66a644c09fbed0a19f3708895c1180df78181019 (patch)
treed89a62f51129b1547ea1b0f70f3c5b61aa7962e0 /Documentation/virt
parente4ee5447927377c55777b73fe497a2455a25f948 (diff)
downloadlinux-66a644c09fbed0a19f3708895c1180df78181019.tar.xz
KVM: guest_memfd: abstract how prepared folios are recorded
Right now, large folios are not supported in guest_memfd, and therefore the order used by kvm_gmem_populate() is always 0. In this scenario, using the up-to-date bit to track prepared-ness is nice and easy because we have one bit available per page. In the future, however, we might have large pages that are partially populated; for example, in the case of SEV-SNP, if a large page has both shared and private areas inside, it is necessary to populate it at a granularity that is smaller than that of the guest_memfd's backing store. In that case we will have to track preparedness at a 4K level, probably as a bitmap. In preparation for that, do not use explicitly folio_test_uptodate() and folio_mark_uptodate(). Return the state of the page directly from __kvm_gmem_get_pfn(), so that it is expected to apply to 2^N pages with N=*max_order. The function to mark a range as prepared for now takes just a folio, but is expected to take also an index and order (or something like that) when large pages are introduced. Thanks to Michael Roth for pointing out the issue with large pages. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'Documentation/virt')
0 files changed, 0 insertions, 0 deletions