On 3/31/2022 1:17 AM, Sean Christopherson wrote: > On Wed, Mar 30, 2022, Nikunj A. Dadhania wrote: >> On 3/29/2022 2:30 AM, Sean Christopherson wrote: >>> Let me preface this by saying I generally like the idea and especially the >>> performance, but... >>> >>> I think we should abandon this approach in favor of committing all our resources >>> to fd-based private memory[*], which (if done right) will provide on-demand pinning >>> for "free". >> >> I will give this a try for SEV, was on my todo list. >> >>> I would much rather get that support merged sooner than later, and use >>> it as a carrot for legacy SEV to get users to move over to its new APIs, with a long >>> term goal of deprecating and disallowing SEV/SEV-ES guests without fd-based private >>> memory. >> >>> That would require guest kernel support to communicate private vs. shared, >> >> Could you explain this in more detail? This is required for punching hole for shared pages? > > Unlike SEV-SNP, which enumerates private vs. shared in the error code, SEV and SEV-ES > don't provide private vs. shared information to the host (KVM) on page fault. And > it's even more fundamental then that, as SEV/SEV-ES won't even fault if the guest > accesses the "wrong" GPA variant, they'll silent consume/corrupt data. > > That means KVM can't support implicit conversions for SEV/SEV-ES, and so an explicit > hypercall is mandatory. SEV doesn't even have a vendor-agnostic guest/host paravirt > ABI, and IIRC SEV-ES doesn't provide a conversion/map hypercall in the GHCB spec, so > running a SEV/SEV-ES guest under UPM would require the guest firmware+kernel to be > properly enlightened beyond what is required architecturally. > So with guest supporting KVM_FEATURE_HC_MAP_GPA_RANGE and host (KVM) supporting KVM_HC_MAP_GPA_RANGE hypercall, SEV/SEV-ES guest should communicate private/shared pages to the hypervisor, this information can be used to mark page shared/private. Regards, Nikunj
