virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>
Cc: Halil Pasic <pasic@linux.ibm.com>,
	linux-s390@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Viktor Mihajlovski <mihajlov@linux.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>, Ram Pai <linuxram@us.ibm.com>,
	Thiago Jung Bauermann <bauerman@linux.ibm.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	"Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
	Michael Mueller <mimu@linux.ibm.com>
Subject: [PATCH 1/2] mm: move force_dma_unencrypted() to mem_encrypt.h
Date: Thu, 20 Feb 2020 17:06:05 +0100	[thread overview]
Message-ID: <20200220160606.53156-2-pasic@linux.ibm.com> (raw)
In-Reply-To: <20200220160606.53156-1-pasic@linux.ibm.com>

Currently force_dma_unencrypted() is only used by the direct
implementation of the DMA API, and thus resides in dma-direct.h. But
there is nothing dma-direct specific about it: if one was -- for
whatever reason -- to implement custom DMA ops that have to in the
encrypted/protected scenarios dma-direct currently deals with, one would
need exactly this kind of information.

More importantly, virtio has to use DMA API (so that the memory
encryption (x86) or protection (power, s390) is handled) under the very
same circumstances force_dma_unencrypted() returns true. Furthermore,
the in these cases the reason to go via the DMA API is distinct,
compared to the reason indicated by VIRTIO_F_IOMMU_PLATFORM: we need to
use DMA API independently of the device's properties with regards to
access to memory. I.e. the addresses in the descriptors are still guest
physical addresses, the device may still be implemented by a SMP CPU,
and thus the device shall use those without any further translation. See
[1].

Let's move force_dma_unencrypted() the so virtio, or other
implementations of DMA ops can make the right decisions.

[1] https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-4100006
(In the spec VIRTIO_F_IOMMU_PLATFORM is called
VIRTIO_F_ACCESS_PLATFORM).

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Tested-by: Ram Pai <linuxram@us.ibm.com>
Tested-by: Michael Mueller <mimu@linux.ibm.com>
---
 include/linux/dma-direct.h  |  9 ---------
 include/linux/mem_encrypt.h | 10 ++++++++++
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 24b8684aa21d..590b15d881b0 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -26,15 +26,6 @@ static inline phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dev_addr)
 }
 #endif /* !CONFIG_ARCH_HAS_PHYS_TO_DMA */
 
-#ifdef CONFIG_ARCH_HAS_FORCE_DMA_UNENCRYPTED
-bool force_dma_unencrypted(struct device *dev);
-#else
-static inline bool force_dma_unencrypted(struct device *dev)
-{
-	return false;
-}
-#endif /* CONFIG_ARCH_HAS_FORCE_DMA_UNENCRYPTED */
-
 /*
  * If memory encryption is supported, phys_to_dma will set the memory encryption
  * bit in the DMA address, and dma_to_phys will clear it.  The raw __phys_to_dma
diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
index 5c4a18a91f89..64a48c4b01a2 100644
--- a/include/linux/mem_encrypt.h
+++ b/include/linux/mem_encrypt.h
@@ -22,6 +22,16 @@ static inline bool mem_encrypt_active(void) { return false; }
 
 #endif	/* CONFIG_ARCH_HAS_MEM_ENCRYPT */
 
+struct device;
+#ifdef CONFIG_ARCH_HAS_FORCE_DMA_UNENCRYPTED
+bool force_dma_unencrypted(struct device *dev);
+#else
+static inline bool force_dma_unencrypted(struct device *dev)
+{
+	return false;
+}
+#endif /* CONFIG_ARCH_HAS_FORCE_DMA_UNENCRYPTED */
+
 #ifdef CONFIG_AMD_MEM_ENCRYPT
 /*
  * The __sme_set() and __sme_clr() macros are useful for adding or removing
-- 
2.17.1

  reply	other threads:[~2020-02-20 16:06 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-20 16:06 [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM Halil Pasic
2020-02-20 16:06 ` Halil Pasic [this message]
2020-02-20 16:11   ` [PATCH 1/2] mm: move force_dma_unencrypted() to mem_encrypt.h Christoph Hellwig
2020-02-20 16:23     ` Christian Borntraeger
2020-02-20 16:31       ` Christoph Hellwig
2020-02-20 17:00         ` Christian Borntraeger
2020-02-21  3:27         ` David Gibson
2020-02-21 13:06           ` Halil Pasic
2020-02-21 15:48             ` Michael S. Tsirkin
2020-02-21 18:07               ` Halil Pasic
2020-02-24  3:33                 ` David Gibson
2020-02-24 18:49                   ` Halil Pasic
2020-02-25 18:08                     ` Cornelia Huck
2020-02-28  0:23                       ` David Gibson
2020-02-20 16:06 ` [PATCH 2/2] virtio: let virtio use DMA API when guest RAM is protected Halil Pasic
2020-02-20 16:13   ` Christoph Hellwig
2020-02-21  2:59     ` David Gibson
2020-02-21  3:41       ` Jason Wang
2020-02-21 13:31         ` Halil Pasic
2020-02-21 13:27       ` Halil Pasic
2020-02-21 16:36       ` Christoph Hellwig
2020-02-24  6:50         ` David Gibson
     [not found]         ` <20200221163645.GB10054-jcswGhMUV9g@public.gmane.org>
2020-02-24 18:59           ` Halil Pasic
2020-02-21 14:33     ` Halil Pasic
2020-02-21 16:39       ` Christoph Hellwig
2020-02-21 18:16         ` Halil Pasic
2020-02-22 19:07       ` Michael S. Tsirkin
2020-02-24 17:16         ` Christoph Hellwig
     [not found]           ` <691d8c8e-665c-b05f-383f-78377fcf6741@amazon.com>
2020-10-28 18:01             ` Michael S. Tsirkin
2020-02-20 20:55   ` Michael S. Tsirkin
2020-02-21  1:17     ` Ram Pai
2020-02-21  3:29       ` David Gibson
2020-02-21 13:12     ` Halil Pasic
2020-02-21 15:39       ` Tom Lendacky
2020-02-24  6:40         ` David Gibson
2020-02-21 15:56       ` Michael S. Tsirkin
2020-02-21 16:35         ` Christoph Hellwig
2020-02-21 18:03         ` Halil Pasic
2020-02-20 20:48 ` [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM Michael S. Tsirkin
2020-02-20 21:29 ` Michael S. Tsirkin
2020-02-21 13:37   ` Halil Pasic
2020-02-20 21:33 ` Michael S. Tsirkin
2020-02-21 13:49   ` Halil Pasic
2020-02-21 16:41   ` Christoph Hellwig
2020-02-24  5:44     ` David Gibson
2020-02-21  6:22 ` Jason Wang
2020-02-21 14:56   ` Halil Pasic
2020-02-24  3:38     ` David Gibson
     [not found]     ` <20200221155602.4de41fa7.pasic-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
2020-02-24  4:01       ` Jason Wang
2020-02-24  6:06         ` Michael S. Tsirkin
2020-02-24  6:45           ` Jason Wang
2020-02-24  7:48             ` Michael S. Tsirkin
2020-02-24  9:26               ` Jason Wang
2020-02-24 13:40                 ` Michael S. Tsirkin
2020-02-25  3:38                   ` Jason Wang
2020-02-24 13:56                 ` Halil Pasic
     [not found]                   ` <20200224145607.2729f47b.pasic-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
2020-02-25  3:30                     ` Jason Wang

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=20200220160606.53156-2-pasic@linux.ibm.com \
    --to=pasic@linux.ibm.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=bauerman@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=frankja@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=m.szyprowski@samsung.com \
    --cc=mihajlov@linux.ibm.com \
    --cc=mimu@linux.ibm.com \
    --cc=mst@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=virtualization@lists.linux-foundation.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;
as well as URLs for NNTP newsgroup(s).