On 10/21/20 6:59 AM, Jason Gunthorpe wrote: > On Mon, Oct 19, 2020 at 11:36:16AM -0500, Tom Lendacky wrote: > >>> io_remap_pfn_range()? Is there use cases where a caller actually wants >>> encrypted io memory? >> >> As long as you never have physical memory / ram being mapped in this path, >> it seems that applying pgprot_decrypted() would be ok. > > I made a patch along these lines: > > https://github.com/jgunthorpe/linux/commit/fc990842983f3530b72fcceafed84bd6075174a1 > > Just waiting for the 0-day bots to check it > > I now have a report that SME works OK but when the same test is done > inside a VM with SEV it fails again - is there something else needed > for the SEV case? Probably. I would assume that it is getting past the MMIO issue, since the above patch should cover SEV, too. But, with SEV, all DMA to and from the guest is unencrypted. I'm not familiar with how the DMA is setup and performed in this situation, but if the DMA is occurring to userspace buffers that are mapped as encrypted, then the resulting access will be ciphertext (either reading unencrypted data from the device as encrypted or writing encrypted data to the device that should be unencrypted). There isn't currently an API to allow userspace to change its mapping from encrypted to unencrypted. > > This would be using VFIO with qemu and KVM to assign the PCI device to > the guest, it seems the guest kernel driver is able to use the device > but the guest userspace fails. In the kernel, the SWIOTLB support is used to bounce the data from encrypted to unencrypted and vice-versa. Thanks, Tom > > Regards, > Jason >
