On Mon, Mar 12, 2018 at 02:48:51PM -0500, Tom Lendacky wrote:
> Ok, I found one issue that allows this to work when the IOMMU isn't
> enabled (see below).
Thanks, folded!
> But the bigger issue is when the IOMMU is enabled. The IOMMU code uses
> a common mapping routine to create the I/O page tables. This routine
> assumes that all memory being mapped is encrypted and therefore sets the
> encryption bit in the I/O page tables. With this patch, the call to
> dma_alloc_direct() now returns un-encrypted memory which results in an
> encryption mis-match. I think keeping dma_alloc_direct() as it was prior
> to this patch is the way to go. It allows SME DMA allocations to remain
> encrypted and avoids added complexity in the amd_iommu.c file. This
> would mean that SEV would still have special DMA operations (so that the
> alloc/free can change the memory to un-encrypted).
>
> What do you think?
In terms of logic you are right. I still don't like keeping a just
slightly tweaked version of dma_alloc_direct around just for this, it
will be perpetually out of sync in terms of features and bug fixes.
What do you think about this version that does the decision at runtime:
http://git.infradead.org/users/hch/misc.git/commitdiff/b89f24dc856595dc7610d672bf077195ab0dabf4
The full tree is available here for testing:
git://git.infradead.org/users/hch/misc.git dma-direct-x86
