From: Borislav Petkov <bp@xxxxxxxxx> Sent: Monday, November 28, 2022 8:34 AM > > On Mon, Nov 28, 2022 at 02:38:11PM +0000, Michael Kelley (LINUX) wrote: > > Any further comment on this patch? I think we're agreement. For > > this patch series I propose to change the symbol "CC_VENDOR_HYPERV" > > to "CC_VENDOR_AMD_VTOM" and the function name > > hyperv_cc_platform_has() to amd_vtom_cc_platform_has(). > > That doesn't sound optimal to me. > > So, let's clarify things first: those Isolation VMs - are they going to > be the paravisors? No. The paravisor exists in another layer (VMPL 0 in the AMD vTOM architecture) that isn't visible to the Linux guest. The paravisor is a separate code base that isn't currently open source. All code in this patch series is code that runs in the Linux guest. >From an encryption standpoint, the Linux guest sees the following: 1) Guest memory is encrypted by default 2) The Linux guest must set the vTOM flag in a PTE to access a page as unencrypted. 3) The Linux guest must explicitly notify the hypervisor to change a page from private (encrypted) to shared (decrypted), and vice versa. > > I don't see any other option because the unmodified guest must be some > old windoze.... What Windows guests do isn't really relevant. Again, the code in this patch series all runs directly in the Linux guest, not the paravisor. And the Linux guest isn't unmodified. We've added changes to understand vTOM and the need to communicate with the hypervisor about page changes between private and shared. But there are other changes for a fully enlightened guest that we don't have to make when using AMD vTOM, because the paravisor transparently (to the guest -- Linux or Windows) handles those issues. > > So, if they're going to be that, then I guess this should be called > > CC_ATTR_PARAVISOR > > to denote that it is a thin layer of virt gunk between an unmodified > guest and a hypervisor. No, the code is this patch series is not that at all. It's not code that is part of the paravisor. It's Linux guest code that understands it is running in an environment where AMD vTOM is the encryption scheme, which is different from the AMD C-bit encryption scheme. > > And if TDX wants to do that too later, then they can use that flag too. > Again, no. What I have proposed as CC_VENDOR_AMD_VTOM is specific to AMD's virtual-Top-of-Memory architecture. The TDX architecture doesn't really have a way to use a paravisor. To summarize, the code in this patch series is about a 3rd encryption scheme that is used by the guest. It is completely parallel to the AMD C-bit encryption scheme and the Intel TDX encryption scheme. With the AMD vTOM scheme, there is a paravisor that transparently emulates some things for the guest so there are fewer code changes needed in the guest, but this patch series is not about that paravisor code. Michael
