public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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;
 }

  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