On Wed, Oct 21, 2020 at 10:30:23AM -0500, Tom Lendacky wrote: > 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. Oh, interesting.. Yes the issue is no userspace DMA stuff uses the DMA API correctly (because it is in userspace) So SWIOTLB tricks don't work, I wish the dma_map could fail for these situations I would have guessed it used some vIOMMU and setup decrpytion just like the host does.. Thanks, Jason
