From: Tom Lendacky <thomas.lendacky@amd.com>
To: Christoph Hellwig <hch@lst.de>
Cc: x86@kernel.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
David Woodhouse <dwmw2@infradead.org>,
Muli Ben-Yehuda <mulix@mulix.org>, Jon Mason <jdmason@kudzu.us>,
Joerg Roedel <joro@8bytes.org>,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 11/13] dma-direct: handle the memory encryption bit in common code
Date: Wed, 14 Mar 2018 10:44:29 -0500 [thread overview]
Message-ID: <69e98163-beca-fb8a-a26b-66dfeef2f689@amd.com> (raw)
In-Reply-To: <20180313131005.GA6260@lst.de>
On 03/13/2018 08:10 AM, Christoph Hellwig wrote:
> 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
>
Thanks for the pointer to the tree. I did find one bug in the
allocation routine, that once fixed (see below), worked with SME
for IOMMU on and off and worked with an SEV guest.
I understand the comment about using sev_active() in the dma-direct
code, maybe we can up with something later to address that.
Thanks,
Tom
diff --git a/lib/dma-direct.c b/lib/dma-direct.c
index 856e140..988a3d8 100644
--- a/lib/dma-direct.c
+++ b/lib/dma-direct.c
@@ -82,10 +82,12 @@ void *dma_direct_alloc(struct device *dev, size_t
size, dma_addr_t *dma_handle,
if (!page)
return NULL;
- *dma_handle = __phys_to_dma(dev, page_to_phys(page));
+ *dma_handle = phys_to_dma(dev, page_to_phys(page));
ret = page_address(page);
- if (sev_active())
+ if (sev_active()) {
+ *dma_handle = __phys_to_dma(dev, page_to_phys(page));
set_memory_decrypted((unsigned long)ret, 1 << page_order);
+ }
memset(ret, 0, size);
return ret;
}
next prev parent reply other threads:[~2018-03-14 15:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-05 17:46 use generic dma-direct and swiotlb code for x86 Christoph Hellwig
2018-03-05 17:46 ` [PATCH 01/13] x86: remove X86_PPRO_FENCE Christoph Hellwig
2018-03-08 21:06 ` Konrad Rzeszutek Wilk
2018-03-05 17:46 ` [PATCH 02/13] x86: remove dma_alloc_coherent_mask Christoph Hellwig
2018-03-08 21:30 ` Konrad Rzeszutek Wilk
2018-03-05 17:46 ` [PATCH 03/13] x86: use dma-direct Christoph Hellwig
2018-03-05 17:46 ` [PATCH 04/13] x86: use generic swiotlb_ops Christoph Hellwig
2018-03-08 16:03 ` Robin Murphy
2018-03-12 8:26 ` Christoph Hellwig
2018-03-05 17:46 ` [PATCH 05/13] x86/amd_gart: look at coherent_dma_mask instead of GFP_DMA Christoph Hellwig
2018-03-05 17:46 ` [PATCH 06/13] x86/amd_gart: use dma_direct_{alloc,free} Christoph Hellwig
2018-03-05 17:46 ` [PATCH 07/13] iommu/amd_iommu: " Christoph Hellwig
2018-03-05 17:46 ` [PATCH 08/13] iommu/intel-iommu: cleanup intel_{alloc,free}_coherent Christoph Hellwig
2018-03-05 17:46 ` [PATCH 09/13] x86: remove dma_alloc_coherent_gfp_flags Christoph Hellwig
2018-03-05 17:46 ` [PATCH 10/13] set_memory.h: provide set_memory_{en,de}crypted stubs Christoph Hellwig
2018-03-05 17:46 ` [PATCH 11/13] dma-direct: handle the memory encryption bit in common code Christoph Hellwig
2018-03-12 18:29 ` Tom Lendacky
2018-03-12 19:48 ` Tom Lendacky
2018-03-13 13:10 ` Christoph Hellwig
2018-03-14 15:44 ` Tom Lendacky [this message]
2018-03-19 10:39 ` Christoph Hellwig
2018-03-19 13:17 ` Tom Lendacky
2018-03-05 17:46 ` [PATCH 12/13] swiotlb: remove swiotlb_set_mem_attributes Christoph Hellwig
2018-03-05 17:46 ` [PATCH 13/13] swiotlb: remove swiotlb_{alloc,free}_coherent Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69e98163-beca-fb8a-a26b-66dfeef2f689@amd.com \
--to=thomas.lendacky@amd.com \
--cc=dwmw2@infradead.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jdmason@kudzu.us \
--cc=joro@8bytes.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mulix@mulix.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox