On 6/14/2017 11:45 AM, Borislav Petkov wrote:
On Wed, Jun 07, 2017 at 02:17:21PM -0500, Tom Lendacky wrote:
Since DMA addresses will effectively look like 48-bit addresses when the
memory encryption mask is set, SWIOTLB is needed if the DMA mask of the
device performing the DMA does not support 48-bits. SWIOTLB will be
initialized to create decrypted bounce buffers for use by these devices.
Signed-off-by: Tom Lendacky <thomas.lendacky@xxxxxxx>
---
...
diff --git a/init/main.c b/init/main.c
index df58a41..7125b5f 100644
--- a/init/main.c
+++ b/init/main.c
@@ -488,6 +488,10 @@ void __init __weak thread_stack_cache_init(void)
}
#endif
+void __init __weak mem_encrypt_init(void)
+{
+}
void __init __weak mem_encrypt_init(void) { }
saves some real estate. Please do that for the rest of the stubs you're
adding, for the next version.
Ok, will do.
Thanks,
Tom
+
/*
* Set up kernel memory allocators
*/
@@ -640,6 +644,15 @@ asmlinkage __visible void __init start_kernel(void)
*/
locking_selftest();
+ /*
+ * This needs to be called before any devices perform DMA
+ * operations that might use the SWIOTLB bounce buffers.
+ * This call will mark the bounce buffers as decrypted so
+ * that their usage will not cause "plain-text" data to be
+ * decrypted when accessed.
s/This call/It/
+ */
+ mem_encrypt_init();
+
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start && !initrd_below_start_ok &&
page_to_pfn(virt_to_page((void *)initrd_start)) < min_low_pfn) {
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index a8d74a7..74d6557 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -30,6 +30,7 @@
#include <linux/highmem.h>
#include <linux/gfp.h>
#include <linux/scatterlist.h>
+#include <linux/mem_encrypt.h>
#include <asm/io.h>
#include <asm/dma.h>
@@ -155,6 +156,17 @@ unsigned long swiotlb_size_or_default(void)
return size ? size : (IO_TLB_DEFAULT_SIZE);
}
+void __weak swiotlb_set_mem_attributes(void *vaddr, unsigned long size)
+{
+}
As above.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
