All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andrea Parri (Microsoft)" <parri.andrea@gmail.com>
To: Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>,
	KY Srinivasan <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Stephen Hemminger <sthemmin@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
	Michael Kelley <mikelley@microsoft.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Peter Anvin <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	iommu@lists.linux.dev, linux-hyperv@vger.kernel.org,
	x86@kernel.org,
	"Andrea Parri (Microsoft)" <parri.andrea@gmail.com>
Subject: [RFC PATCH 1/2] swiotlb,dma-direct: Move swiotlb_unencrypted_base to direct.c
Date: Wed,  6 Jul 2022 21:50:26 +0200	[thread overview]
Message-ID: <20220706195027.76026-2-parri.andrea@gmail.com> (raw)
In-Reply-To: <20220706195027.76026-1-parri.andrea@gmail.com>

The variable will come in handy to enable dma_direct_{alloc,free}()
for Hyper-V AMD SEV-SNP Isolated VMs.

Rename swiotlb_unencrypted_base to dma_unencrypted_base to indicate
that the notion is not restricted to SWIOTLB.

No functional change.

Suggested-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
---
Yeah, this is in some sense trading the dependency on SWIOTLB for a
dependency on HAS_DMA:

Q1. I'm unable to envision a scenario where SWIOTLB without HAS_DMA
would make sense but I'm also expecting one of the kernel test bots
to try such a nonsensical configuration... should the references to
dma_unencrypted_base in swiotlb.c be protected with HAS_DMA? other?

Q2. Can the #ifdef CONFIG_HAS_DMA in arch/x86/kernel/cpu/mshyperv.c
be removed? can we make HYPERV "depends on HAS_DMA"?

...

 arch/x86/kernel/cpu/mshyperv.c |  6 +++---
 include/linux/dma-direct.h     |  2 ++
 include/linux/swiotlb.h        |  2 --
 kernel/dma/direct.c            |  8 ++++++++
 kernel/dma/swiotlb.c           | 12 +++++-------
 5 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 831613959a92a..47e9cece86ff8 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -18,7 +18,7 @@
 #include <linux/kexec.h>
 #include <linux/i8253.h>
 #include <linux/random.h>
-#include <linux/swiotlb.h>
+#include <linux/dma-direct.h>
 #include <asm/processor.h>
 #include <asm/hypervisor.h>
 #include <asm/hyperv-tlfs.h>
@@ -333,8 +333,8 @@ static void __init ms_hyperv_init_platform(void)
 
 		if (hv_get_isolation_type() == HV_ISOLATION_TYPE_SNP) {
 			static_branch_enable(&isolation_type_snp);
-#ifdef CONFIG_SWIOTLB
-			swiotlb_unencrypted_base = ms_hyperv.shared_gpa_boundary;
+#ifdef CONFIG_HAS_DMA
+			dma_unencrypted_base = ms_hyperv.shared_gpa_boundary;
 #endif
 		}
 		/* Isolation VMs are unenlightened SEV-based VMs, thus this check: */
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 18aade195884d..0b7e4c4b7b34c 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -14,6 +14,8 @@
 
 extern unsigned int zone_dma_bits;
 
+extern phys_addr_t dma_unencrypted_base;
+
 /*
  * Record the mapping of CPU physical to DMA addresses for a given region.
  */
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 7ed35dd3de6e7..fa2e85f21af61 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -190,6 +190,4 @@ static inline bool is_swiotlb_for_alloc(struct device *dev)
 }
 #endif /* CONFIG_DMA_RESTRICTED_POOL */
 
-extern phys_addr_t swiotlb_unencrypted_base;
-
 #endif /* __LINUX_SWIOTLB_H */
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 8d0b68a170422..06b2b901e37a3 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -22,6 +22,14 @@
  */
 unsigned int zone_dma_bits __ro_after_init = 24;
 
+/*
+ * Certain Confidential Computing solutions, such as Hyper-V AMD SEV-SNP
+ * isolated VMs, use dma_unencrypted_base as a watermark: memory addresses
+ * below dma_unencrypted_base are treated as private, while memory above
+ * dma_unencrypted_base is treated as shared.
+ */
+phys_addr_t dma_unencrypted_base;
+
 static inline dma_addr_t phys_to_dma_direct(struct device *dev,
 		phys_addr_t phys)
 {
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index cb50f8d383606..78d4f5294a56c 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -67,8 +67,6 @@ static bool swiotlb_force_disable;
 
 struct io_tlb_mem io_tlb_default_mem;
 
-phys_addr_t swiotlb_unencrypted_base;
-
 static unsigned long default_nslabs = IO_TLB_DEFAULT_SIZE >> IO_TLB_SHIFT;
 
 static int __init
@@ -142,7 +140,7 @@ static inline unsigned long nr_slots(u64 val)
 
 /*
  * Remap swioltb memory in the unencrypted physical address space
- * when swiotlb_unencrypted_base is set. (e.g. for Hyper-V AMD SEV-SNP
+ * when dma_unencrypted_base is set. (e.g. for Hyper-V AMD SEV-SNP
  * Isolation VMs).
  */
 #ifdef CONFIG_HAS_IOMEM
@@ -150,8 +148,8 @@ static void *swiotlb_mem_remap(struct io_tlb_mem *mem, unsigned long bytes)
 {
 	void *vaddr = NULL;
 
-	if (swiotlb_unencrypted_base) {
-		phys_addr_t paddr = mem->start + swiotlb_unencrypted_base;
+	if (dma_unencrypted_base) {
+		phys_addr_t paddr = mem->start + dma_unencrypted_base;
 
 		vaddr = memremap(paddr, bytes, MEMREMAP_WB);
 		if (!vaddr)
@@ -213,10 +211,10 @@ static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t start,
 	}
 
 	/*
-	 * If swiotlb_unencrypted_base is set, the bounce buffer memory will
+	 * If dma_unencrypted_base is set, the bounce buffer memory will
 	 * be remapped and cleared in swiotlb_update_mem_attributes.
 	 */
-	if (swiotlb_unencrypted_base)
+	if (dma_unencrypted_base)
 		return;
 
 	memset(vaddr, 0, bytes);
-- 
2.25.1


  reply	other threads:[~2022-07-06 19:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-06 19:50 [RFC PATCH 0/2] dma_direct_{alloc,free}() for Hyper-V IVMs Andrea Parri (Microsoft)
2022-07-06 19:50 ` Andrea Parri (Microsoft) [this message]
2022-07-06 19:50 ` [RFC PATCH 2/2] dma-direct: Fix dma_direct_{alloc,free}() for Hyperv-V IVMs Andrea Parri (Microsoft)
2022-07-07  5:58   ` Christoph Hellwig
2022-07-07 14:20     ` Andrea Parri

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=20220706195027.76026-2-parri.andrea@gmail.com \
    --to=parri.andrea@gmail.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=decui@microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=hch@lst.de \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=iommu@lists.linux.dev \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mikelley@microsoft.com \
    --cc=mingo@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=sthemmin@microsoft.com \
    --cc=tglx@linutronix.de \
    --cc=wei.liu@kernel.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 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.