On Wed, Dec 15, 2021 at 01:00:38PM +0800, Tianyu Lan wrote: > > > On 12/15/2021 6:40 AM, Dave Hansen wrote: > > On 12/14/21 2:23 PM, Tom Lendacky wrote: > > > > I don't really understand how this can be more general any *not* get > > > > utilized by the existing SEV support. > > > > > > The Virtual Top-of-Memory (VTOM) support is an SEV-SNP feature that is > > > meant to be used with a (relatively) un-enlightened guest. The idea is > > > that the C-bit in the guest page tables must be 0 for all accesses. It > > > is only the physical address relative to VTOM that determines if the > > > access is encrypted or not. So setting sme_me_mask will actually cause > > > issues when running with this feature. Since all DMA for an SEV-SNP > > > guest must still be to shared (unencrypted) memory, some enlightenment > > > is needed. In this case, memory mapped above VTOM will provide that via > > > the SWIOTLB update. For SEV-SNP guests running with VTOM, they are > > > likely to also be running with the Reflect #VC feature, allowing a > > > "paravisor" to handle any #VCs generated by the guest. > > > > > > See sections 15.36.8 "Virtual Top-of-Memory" and 15.36.9 "Reflect #VC" > > > in volume 2 of the AMD APM [1]. > > > > Thanks, Tom, that's pretty much what I was looking for. > > > > The C-bit normally comes from the page tables. But, the hardware also > > provides an alternative way to effectively get C-bit behavior without > > actually setting the bit in the page tables: Virtual Top-of-Memory > > (VTOM). Right? > > > > It sounds like Hyper-V has chosen to use VTOM instead of requiring the > > guest to do the C-bit in its page tables. > > > > But, the thing that confuses me is when you said: "it (VTOM) is meant to > > be used with a (relatively) un-enlightened guest". We don't have an > > unenlightened guest here. We have Linux, which is quite enlightened. > > > > > Is VTOM being used because there's something that completely rules out > > > using the C-bit in the page tables? What's that "something"? > > > For "un-enlightened" guest, there is an another system running insider > the VM to emulate some functions(tsc, timer, interrupt and so on) and > this helps not to modify OS(Linux/Windows) a lot. In Hyper-V Isolation > VM, we called the new system as HCL/paravisor. HCL runs in the VMPL0 and > Linux runs in VMPL2. This is similar with nested virtualization. HCL > plays similar role as L1 hypervisor to emulate some general functions > (e.g, rdmsr/wrmsr accessing and interrupt injection) which needs to be > enlightened in the enlightened guest. Linux kernel needs to handle > #vc/#ve exception directly in the enlightened guest. HCL handles such > exception in un-enlightened guest and emulate interrupt injection which > helps not to modify OS core part code. Using vTOM also is same purpose. > Hyper-V uses vTOM avoid changing page table related code in OS(include > Windows and Linux)and just needs to map memory into decrypted address > space above vTOM in the driver code. > > Linux has generic swiotlb bounce buffer implementation and so introduce > swiotlb_unencrypted_base here to set shared memory boundary or vTOM. > Hyper-V Isolation VM is un-enlightened guest. Hyper-V doesn't expose sev/sme > capability to guest and so SEV code actually doesn't work. > So we also can't interact current existing SEV code and these code is > for enlightened guest support without HCL/paravisor. If other platforms > or SEV want to use similar vTOM feature, swiotlb_unencrypted_base can > be reused. So swiotlb_unencrypted_base is a general solution for all > platforms besides SEV and Hyper-V. > Thanks for the detailed explanation. Dave, are you happy with this? The code looks pretty solid to my untrained eyes. And the series has collected necessary acks from stakeholders. If I don't hear objection by EOD Friday I will apply this series to hyperv-next. Wei.
