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.
