All of lore.kernel.org
 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: linux-s390@vger.kernel.org, Janosch Frank <frankja@linux.ibm.com>,
	"Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
	Cornelia Huck <cohuck@redhat.com>, Ram Pai <linuxram@us.ibm.com>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	iommu@lists.linux-foundation.org,
	Michael Mueller <mimu@linux.ibm.com>,
	Viktor Mihajlovski <mihajlov@linux.ibm.com>,
	David Gibson <david@gibson.dropbear.id.au>
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

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
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:08 UTC|newest]

Thread overview: 124+ 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
2020-02-20 16:06 ` Halil Pasic [this message]
2020-02-20 16:06   ` [PATCH 1/2] mm: move force_dma_unencrypted() to mem_encrypt.h Halil Pasic
2020-02-20 16:11   ` Christoph Hellwig
2020-02-20 16:11     ` Christoph Hellwig
2020-02-20 16:23     ` Christian Borntraeger
2020-02-20 16:23       ` Christian Borntraeger
2020-02-20 16:31       ` Christoph Hellwig
2020-02-20 16:31         ` Christoph Hellwig
2020-02-20 16:31         ` Christoph Hellwig
2020-02-20 17:00         ` Christian Borntraeger
2020-02-20 17:00           ` Christian Borntraeger
2020-02-21  3:27         ` David Gibson
2020-02-21  3:27           ` David Gibson
2020-02-21 13:06           ` Halil Pasic
2020-02-21 13:06             ` Halil Pasic
2020-02-21 15:48             ` Michael S. Tsirkin
2020-02-21 15:48               ` Michael S. Tsirkin
2020-02-21 18:07               ` Halil Pasic
2020-02-21 18:07                 ` Halil Pasic
2020-02-24  3:33                 ` David Gibson
2020-02-24  3:33                   ` David Gibson
2020-02-24 18:49                   ` Halil Pasic
2020-02-24 18:49                     ` Halil Pasic
2020-02-25 18:08                     ` Cornelia Huck
2020-02-25 18:08                       ` Cornelia Huck
2020-02-28  0:23                       ` David Gibson
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:06   ` Halil Pasic
2020-02-20 16:13   ` Christoph Hellwig
2020-02-20 16:13     ` Christoph Hellwig
2020-02-21  2:59     ` David Gibson
2020-02-21  2:59       ` David Gibson
2020-02-21  3:41       ` Jason Wang
2020-02-21  3:41         ` Jason Wang
2020-02-21 13:31         ` Halil Pasic
2020-02-21 13:31           ` Halil Pasic
2020-02-21 13:27       ` Halil Pasic
2020-02-21 13:27         ` Halil Pasic
2020-02-21 16:36       ` Christoph Hellwig
2020-02-21 16:36         ` Christoph Hellwig
2020-02-24  6:50         ` David Gibson
2020-02-24  6:50           ` David Gibson
2020-02-24 18:59         ` Halil Pasic
2020-02-24 18:59           ` Halil Pasic
2020-02-24 18:59           ` Halil Pasic
2020-02-21 14:33     ` Halil Pasic
2020-02-21 14:33       ` Halil Pasic
2020-02-21 16:39       ` Christoph Hellwig
2020-02-21 16:39         ` Christoph Hellwig
2020-02-21 18:16         ` Halil Pasic
2020-02-21 18:16           ` Halil Pasic
2020-02-21 18:16           ` Halil Pasic
2020-02-22 19:07       ` Michael S. Tsirkin
2020-02-22 19:07         ` Michael S. Tsirkin
2020-02-24 17:16         ` Christoph Hellwig
2020-02-24 17:16           ` Christoph Hellwig
2020-10-28 14:24           ` Alexander Graf via iommu
2020-10-28 18:01             ` Michael S. Tsirkin
2020-10-28 18:01               ` Michael S. Tsirkin
2020-10-28 18:01               ` Michael S. Tsirkin
2020-02-20 20:55   ` Michael S. Tsirkin
2020-02-20 20:55     ` Michael S. Tsirkin
2020-02-21  1:17     ` Ram Pai
2020-02-21  1:17       ` Ram Pai
2020-02-21  1:17       ` Ram Pai
2020-02-21  3:29       ` David Gibson
2020-02-21  3:29         ` David Gibson
2020-02-21 13:12     ` Halil Pasic
2020-02-21 13:12       ` Halil Pasic
2020-02-21 15:39       ` Tom Lendacky
2020-02-21 15:39         ` Tom Lendacky
2020-02-24  6:40         ` David Gibson
2020-02-24  6:40           ` David Gibson
2020-02-24  6:40           ` David Gibson
2020-02-21 15:56       ` Michael S. Tsirkin
2020-02-21 15:56         ` Michael S. Tsirkin
2020-02-21 16:35         ` Christoph Hellwig
2020-02-21 16:35           ` Christoph Hellwig
2020-02-21 18:03         ` Halil Pasic
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 20:48   ` Michael S. Tsirkin
2020-02-20 21:29 ` Michael S. Tsirkin
2020-02-20 21:29   ` Michael S. Tsirkin
2020-02-21 13:37   ` Halil Pasic
2020-02-21 13:37     ` Halil Pasic
2020-02-20 21:33 ` Michael S. Tsirkin
2020-02-20 21:33   ` Michael S. Tsirkin
2020-02-21 13:49   ` Halil Pasic
2020-02-21 13:49     ` Halil Pasic
2020-02-21 16:41   ` Christoph Hellwig
2020-02-21 16:41     ` Christoph Hellwig
2020-02-24  5:44     ` David Gibson
2020-02-24  5:44       ` David Gibson
2020-02-24  5:44       ` David Gibson
2020-02-21  6:22 ` Jason Wang
2020-02-21  6:22   ` Jason Wang
2020-02-21 14:56   ` Halil Pasic
2020-02-21 14:56     ` Halil Pasic
2020-02-24  3:38     ` David Gibson
2020-02-24  3:38       ` David Gibson
2020-02-24  4:01     ` Jason Wang
2020-02-24  4:01       ` Jason Wang
2020-02-24  4:01       ` Jason Wang
2020-02-24  6:06       ` Michael S. Tsirkin
2020-02-24  6:06         ` Michael S. Tsirkin
2020-02-24  6:45         ` Jason Wang
2020-02-24  6:45           ` Jason Wang
2020-02-24  7:48           ` Michael S. Tsirkin
2020-02-24  7:48             ` Michael S. Tsirkin
2020-02-24  9:26             ` Jason Wang
2020-02-24  9:26               ` Jason Wang
2020-02-24 13:40               ` Michael S. Tsirkin
2020-02-24 13:40                 ` Michael S. Tsirkin
2020-02-25  3:38                 ` Jason Wang
2020-02-25  3:38                   ` Jason Wang
2020-02-24 13:56               ` Halil Pasic
2020-02-24 13:56                 ` Halil Pasic
2020-02-25  3:30                 ` Jason Wang
2020-02-25  3:30                   ` Jason Wang
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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.