From: Borislav Petkov <bp@xxxxxxxxx> Sent: Monday, January 9, 2023 10:47 AM > > On Thu, Dec 01, 2022 at 07:30:18PM -0800, Michael Kelley wrote: > > This patch series adds support for PCI pass-thru devices to Hyper-V > > Confidential VMs (also called "Isolation VMs"). But in preparation, it > > first changes how private (encrypted) vs. shared (decrypted) memory is > > handled in Hyper-V SEV-SNP guest VMs. The new approach builds on the > > confidential computing (coco) mechanisms introduced in the 5.19 kernel > > for TDX support and significantly reduces the amount of Hyper-V specific > > code. Furthermore, with this new approach a proposed RFC patch set for > > generic DMA layer functionality[1] is no longer necessary. > > In any case, this is starting to get ready - how do we merge this? > > I apply the x86 bits and give Wei an immutable branch to add the rest of the > HyperV stuff ontop? > > -- > Regards/Gruss, > Boris. > I'll let Wei respond on handling the merging. I'll spin a v5 in a few days. Changes will be: * Address your comments * Use PAGE_KERNEL in the arch independent Hyper-V code instead of PAGE_KERNEL_NOENC. PAGE_KERNEL_NOENC doesn't exist for ARM64, so it causes compile errors when building for ARM64. Using PAGE_KERNEL means getting sme_me_mask when on x86, but that value will be zero for vTOM VMs. * Fix a problem with the virtual TPM device getting mapped decrypted. Like the IOAPIC, the vTPM is provided by the paravisor, and needs to be mapped encrypted. My thinking is to allow hypervisor initialization code to specify a guest physical address range to be treated as encrypted, and add a check against that range in __ioremap_check_other(), similar to what is done for EFI memory. Thoughts? I don't want to change the vTPM driver, and the devm_* interfaces it uses don't provide an option to map encrypted anyway. But I'm open to other ideas. Thanks for the review! Michael
