* [RFC PATCH 08/11] powerpc: Add and use LPPACA_SIZE constant
From: Thiago Jung Bauermann @ 2018-08-24 2:59 UTC (permalink / raw)
To: linuxppc-dev
Cc: iommu, linux-kernel, Alexey Kardashevskiy, Anshuman Khandual,
Benjamin Herrenschmidt, Christoph Hellwig, Michael Ellerman,
Mike Anderson, Paul Mackerras, Ram Pai, Thiago Jung Bauermann
In-Reply-To: <20180824025933.24319-1-bauerman@linux.ibm.com>
Helps document what the hard-coded number means.
Suggested-by: Alexey Kardashevskiy <aik@linux.ibm.com>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
---
arch/powerpc/kernel/paca.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 0ee3e6d50f28..1edf8695019d 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -24,6 +24,8 @@
#define boot_cpuid 0
#endif
+#define LPPACA_SIZE 0x400
+
static void *__init alloc_paca_data(unsigned long size, unsigned long align,
unsigned long limit, int cpu)
{
@@ -70,7 +72,7 @@ static inline void init_lppaca(struct lppaca *lppaca)
*lppaca = (struct lppaca) {
.desc = cpu_to_be32(0xd397d781), /* "LpPa" */
- .size = cpu_to_be16(0x400),
+ .size = cpu_to_be16(LPPACA_SIZE),
.fpregs_in_use = 1,
.slb_count = cpu_to_be16(64),
.vmxregs_in_use = 0,
@@ -80,14 +82,13 @@ static inline void init_lppaca(struct lppaca *lppaca)
static struct lppaca * __init new_lppaca(int cpu, unsigned long limit)
{
struct lppaca *lp;
- size_t size = 0x400;
- BUILD_BUG_ON(size < sizeof(struct lppaca));
+ BUILD_BUG_ON(LPPACA_SIZE < sizeof(struct lppaca));
if (early_cpu_has_feature(CPU_FTR_HVMODE))
return NULL;
- lp = alloc_paca_data(size, 0x400, limit, cpu);
+ lp = alloc_paca_data(LPPACA_SIZE, 0x400, limit, cpu);
init_lppaca(lp);
return lp;
^ permalink raw reply related
* [RFC PATCH 07/11] powerpc/svm: Use shared memory for Debug Trace Log (DTL)
From: Thiago Jung Bauermann @ 2018-08-24 2:59 UTC (permalink / raw)
To: linuxppc-dev
Cc: iommu, linux-kernel, Alexey Kardashevskiy, Anshuman Khandual,
Benjamin Herrenschmidt, Christoph Hellwig, Michael Ellerman,
Mike Anderson, Paul Mackerras, Ram Pai, Anshuman Khandual,
Thiago Jung Bauermann
In-Reply-To: <20180824025933.24319-1-bauerman@linux.ibm.com>
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
On Ultravisor platform kmem_cache for DTL buffers must use a constructor
function which converts the underlying buddy allocated SLUB cache pages
into shared memory so that they are accessible to the hypervisor.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
---
arch/powerpc/include/asm/svm.h | 1 +
arch/powerpc/kernel/svm.c | 30 ++++++++++++++++++++++++++++++
arch/powerpc/platforms/pseries/setup.c | 5 ++++-
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/svm.h b/arch/powerpc/include/asm/svm.h
index 95d69e472e52..e00688761704 100644
--- a/arch/powerpc/include/asm/svm.h
+++ b/arch/powerpc/include/asm/svm.h
@@ -16,6 +16,7 @@ static bool is_svm_platform(void)
extern void mem_convert_shared(unsigned long pfn, unsigned long npages);
extern void mem_convert_secure(unsigned long pfn, unsigned long npages);
+extern void dtl_cache_ctor(void *addr);
#else
static inline bool is_svm_platform(void)
{
diff --git a/arch/powerpc/kernel/svm.c b/arch/powerpc/kernel/svm.c
index 891db2de8c04..1af5caa955f5 100644
--- a/arch/powerpc/kernel/svm.c
+++ b/arch/powerpc/kernel/svm.c
@@ -66,3 +66,33 @@ int set_memory_decrypted(unsigned long addr, int numpages)
return 0;
}
+
+/* There's one dispatch log per CPU. */
+#define NR_DTL_PAGE (DISPATCH_LOG_BYTES * CONFIG_NR_CPUS / PAGE_SIZE)
+
+static struct page *dtl_page_store[NR_DTL_PAGE];
+static long dtl_nr_pages;
+
+static bool is_dtl_page_shared(struct page *page)
+{
+ long i;
+
+ for (i = 0; i < dtl_nr_pages; i++)
+ if (dtl_page_store[i] == page)
+ return true;
+
+ return false;
+}
+
+void dtl_cache_ctor(void *addr)
+{
+ unsigned long pfn = PHYS_PFN(__pa(addr));
+ struct page *page = pfn_to_page(pfn);
+
+ if (!is_dtl_page_shared(page)) {
+ dtl_page_store[dtl_nr_pages] = page;
+ dtl_nr_pages++;
+ WARN_ON(dtl_nr_pages >= NR_DTL_PAGE);
+ mem_convert_shared(pfn, PAGE_SIZE);
+ }
+}
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 139f0af6c3d9..50ba77c802d2 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -69,6 +69,7 @@
#include <asm/kexec.h>
#include <asm/isa-bridge.h>
#include <asm/security_features.h>
+#include <asm/svm.h>
#include "pseries.h"
@@ -288,8 +289,10 @@ static inline int alloc_dispatch_logs(void)
static int alloc_dispatch_log_kmem_cache(void)
{
+ void (*ctor)(void *) = is_svm_platform() ? dtl_cache_ctor : NULL;
+
dtl_cache = kmem_cache_create("dtl", DISPATCH_LOG_BYTES,
- DISPATCH_LOG_BYTES, 0, NULL);
+ DISPATCH_LOG_BYTES, 0, ctor);
if (!dtl_cache) {
pr_warn("Failed to create dispatch trace log buffer cache\n");
pr_warn("Stolen time statistics will be unreliable\n");
^ permalink raw reply related
* [RFC PATCH 06/11] powerpc/svm: Use SWIOTLB DMA API for all virtio devices
From: Thiago Jung Bauermann @ 2018-08-24 2:59 UTC (permalink / raw)
To: linuxppc-dev
Cc: iommu, linux-kernel, Alexey Kardashevskiy, Anshuman Khandual,
Benjamin Herrenschmidt, Christoph Hellwig, Michael Ellerman,
Mike Anderson, Paul Mackerras, Ram Pai, Anshuman Khandual,
Thiago Jung Bauermann
In-Reply-To: <20180824025933.24319-1-bauerman@linux.ibm.com>
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Secure guest memory (GPA range) is isolated and inaccessible from the host.
But virtio ring transactions require the back end drivers to process
incoming scatter gather buffers which require their access in host. Hence a
portion of guest memory can be converted to shared memory and all buffers
need to be bounced into the pool before being passed on to the host.
SWIOTLB buffers can be pre-allocated and converted as shared memory during
early boot. Generic SWIOTLB DMA API (swiotlb_dma_ops) callbacks can be used
to bounce each incoming scatter gather I/O buffer addresses into this pool
of shared memory before being passed on to the host. All virtio devices on
secure guest platform need to use generic SWIOTLB DMA API. Utilize the new
virtio core platform hook platform_override_dma_ops() to achieve this.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
---
arch/powerpc/platforms/pseries/iommu.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 5773bc7eb4bd..56b894d65dba 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -39,6 +39,7 @@
#include <linux/iommu.h>
#include <linux/rculist.h>
#include <linux/virtio.h>
+#include <linux/virtio_config.h>
#include <asm/io.h>
#include <asm/prom.h>
#include <asm/rtas.h>
@@ -51,6 +52,7 @@
#include <asm/udbg.h>
#include <asm/mmzone.h>
#include <asm/plpar_wrappers.h>
+#include <asm/svm.h>
#include "pseries.h"
@@ -1400,5 +1402,7 @@ machine_subsys_initcall_sync(pseries, tce_iommu_bus_notifier_init);
void platform_override_dma_ops(struct virtio_device *vdev)
{
- /* Override vdev->parent.dma_ops if required */
+ if (is_svm_platform() &&
+ !virtio_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM))
+ set_dma_ops(vdev->dev.parent, &swiotlb_dma_ops);
}
^ permalink raw reply related
* [RFC PATCH 05/11] powerpc/svm: Don't release SWIOTLB buffers on secure guests
From: Thiago Jung Bauermann @ 2018-08-24 2:59 UTC (permalink / raw)
To: linuxppc-dev
Cc: iommu, linux-kernel, Alexey Kardashevskiy, Anshuman Khandual,
Benjamin Herrenschmidt, Christoph Hellwig, Michael Ellerman,
Mike Anderson, Paul Mackerras, Ram Pai, Anshuman Khandual,
Thiago Jung Bauermann
In-Reply-To: <20180824025933.24319-1-bauerman@linux.ibm.com>
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Even though SWIOTLB slab gets allocated and initialized on each powerpc
platform with swiotlb_init(), it gets released away again on all server
platforms because ppc_swiotlb_enable variable never gets set. Secure
guests would require SWIOTLB DMA API support for virtio bounce buffering
purpose. Hence retain the allocated buffer by setting ppc_swiotlb_enable
variable for secure guests on Ultravisor platforms.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
---
arch/powerpc/kernel/svm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/svm.c b/arch/powerpc/kernel/svm.c
index eab2a64d8643..891db2de8c04 100644
--- a/arch/powerpc/kernel/svm.c
+++ b/arch/powerpc/kernel/svm.c
@@ -16,6 +16,7 @@ static int __init init_svm(void)
if (!is_svm_platform())
return 0;
+ ppc_swiotlb_enable = 1;
swiotlb_update_mem_attributes();
return 0;
^ permalink raw reply related
* [RFC PATCH 04/11] powerpc/svm: Convert SWIOTLB buffers to shared memory
From: Thiago Jung Bauermann @ 2018-08-24 2:59 UTC (permalink / raw)
To: linuxppc-dev
Cc: iommu, linux-kernel, Alexey Kardashevskiy, Anshuman Khandual,
Benjamin Herrenschmidt, Christoph Hellwig, Michael Ellerman,
Mike Anderson, Paul Mackerras, Ram Pai, Anshuman Khandual,
Thiago Jung Bauermann
In-Reply-To: <20180824025933.24319-1-bauerman@linux.ibm.com>
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Hook the shared memory conversion functions into the ARCH_HAS_MEM_ENCRYPT
framework and call swiotlb_update_mem_attributes() to convert SWIOTLB's
buffers to shared memory.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
---
arch/powerpc/Kconfig | 4 ++++
arch/powerpc/include/asm/mem_encrypt.h | 19 +++++++++++++++++++
arch/powerpc/kernel/svm.c | 34 ++++++++++++++++++++++++++++++++++
3 files changed, 57 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 90f73d15f58a..1466d1234723 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -440,12 +440,16 @@ config MATH_EMULATION_HW_UNIMPLEMENTED
endchoice
+config ARCH_HAS_MEM_ENCRYPT
+ def_bool n
+
config PPC_SVM
bool "Secure virtual machine (SVM) support for POWERPC"
default n
depends on PPC_PSERIES
select DMA_DIRECT_OPS
select SWIOTLB
+ select ARCH_HAS_MEM_ENCRYPT
help
Support secure guests on POWERPC. There are certain POWER platforms
which support secure guests with the help of an Ultravisor executing
diff --git a/arch/powerpc/include/asm/mem_encrypt.h b/arch/powerpc/include/asm/mem_encrypt.h
new file mode 100644
index 000000000000..2b6e37ea446c
--- /dev/null
+++ b/arch/powerpc/include/asm/mem_encrypt.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * SVM helper functions
+ *
+ * Copyright 2018 IBM Corporation
+ */
+
+#ifndef _ASM_POWERPC_MEM_ENCRYPT_H
+#define _ASM_POWERPC_MEM_ENCRYPT_H
+
+#define sme_me_mask 0ULL
+
+static inline bool sme_active(void) { return false; }
+static inline bool sev_active(void) { return false; }
+
+int set_memory_encrypted(unsigned long addr, int numpages);
+int set_memory_decrypted(unsigned long addr, int numpages);
+
+#endif /* _ASM_POWERPC_MEM_ENCRYPT_H */
diff --git a/arch/powerpc/kernel/svm.c b/arch/powerpc/kernel/svm.c
index 37437cf92df5..eab2a64d8643 100644
--- a/arch/powerpc/kernel/svm.c
+++ b/arch/powerpc/kernel/svm.c
@@ -7,6 +7,20 @@
*/
#include <linux/mm.h>
+#include <linux/swiotlb.h>
+#include <asm/machdep.h>
+#include <asm/svm.h>
+
+static int __init init_svm(void)
+{
+ if (!is_svm_platform())
+ return 0;
+
+ swiotlb_update_mem_attributes();
+
+ return 0;
+}
+machine_early_initcall(pseries, init_svm);
void mem_convert_shared(unsigned long pfn, unsigned long npages)
{
@@ -31,3 +45,23 @@ void mem_convert_secure(unsigned long pfn, unsigned long npages)
* ucall_convert_secure(paddr, size)
*/
}
+
+int set_memory_encrypted(unsigned long addr, int numpages)
+{
+ if (!PAGE_ALIGNED(addr))
+ return -EINVAL;
+
+ mem_convert_secure(PHYS_PFN(__pa(addr)), numpages);
+
+ return 0;
+}
+
+int set_memory_decrypted(unsigned long addr, int numpages)
+{
+ if (!PAGE_ALIGNED(addr))
+ return -EINVAL;
+
+ mem_convert_shared(PHYS_PFN(__pa(addr)), numpages);
+
+ return 0;
+}
^ permalink raw reply related
* [RFC PATCH 03/11] powerpc/svm: Add memory conversion (shared/secure) helper functions
From: Thiago Jung Bauermann @ 2018-08-24 2:59 UTC (permalink / raw)
To: linuxppc-dev
Cc: iommu, linux-kernel, Alexey Kardashevskiy, Anshuman Khandual,
Benjamin Herrenschmidt, Christoph Hellwig, Michael Ellerman,
Mike Anderson, Paul Mackerras, Ram Pai, Anshuman Khandual,
Thiago Jung Bauermann
In-Reply-To: <20180824025933.24319-1-bauerman@linux.ibm.com>
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Add the following helper functions to convert PAGE_SIZE aligned memory
buffers as shared or secure (i.e., accessible to the hypervisor or not) via
Ultravisor calls.
1. mem_convert_shared(unsigned long pfn, unsigned long npages)
2. mem_convert_secure(unsigned long pfn, unsigned long npages)
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
---
arch/powerpc/include/asm/svm.h | 3 +++
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/svm.c | 33 +++++++++++++++++++++++++++++++++
3 files changed, 37 insertions(+)
diff --git a/arch/powerpc/include/asm/svm.h b/arch/powerpc/include/asm/svm.h
index 6f89e5d6d37f..95d69e472e52 100644
--- a/arch/powerpc/include/asm/svm.h
+++ b/arch/powerpc/include/asm/svm.h
@@ -13,6 +13,9 @@ static bool is_svm_platform(void)
{
return mfmsr() & MSR_S;
}
+
+extern void mem_convert_shared(unsigned long pfn, unsigned long npages);
+extern void mem_convert_secure(unsigned long pfn, unsigned long npages);
#else
static inline bool is_svm_platform(void)
{
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 2b4c40b255e4..98780b4e924c 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -113,6 +113,7 @@ ifeq ($(CONFIG_HAVE_IMA_KEXEC)$(CONFIG_IMA),yy)
obj-y += ima_kexec.o
endif
+obj-$(CONFIG_PPC_SVM) += svm.o
obj-$(CONFIG_AUDIT) += audit.o
obj64-$(CONFIG_AUDIT) += compat_audit.o
diff --git a/arch/powerpc/kernel/svm.c b/arch/powerpc/kernel/svm.c
new file mode 100644
index 000000000000..37437cf92df5
--- /dev/null
+++ b/arch/powerpc/kernel/svm.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Secure VM platform
+ *
+ * Copyright 2018 IBM Corporation
+ * Author: Anshuman Khandual <khandual@linux.vnet.ibm.com>
+ */
+
+#include <linux/mm.h>
+
+void mem_convert_shared(unsigned long pfn, unsigned long npages)
+{
+ if (!pfn_valid(pfn))
+ return;
+
+ /*
+ * FIXME: Insert real UV call when ready
+ *
+ * ucall_convert_shared(paddr, size)
+ */
+}
+
+void mem_convert_secure(unsigned long pfn, unsigned long npages)
+{
+ if (!pfn_valid(pfn))
+ return;
+
+ /*
+ * FIXME: Insert real UV call when ready
+ *
+ * ucall_convert_secure(paddr, size)
+ */
+}
^ permalink raw reply related
* [RFC PATCH 02/11] powerpc/svm: Select CONFIG_DMA_DIRECT_OPS and CONFIG_SWIOTLB
From: Thiago Jung Bauermann @ 2018-08-24 2:59 UTC (permalink / raw)
To: linuxppc-dev
Cc: iommu, linux-kernel, Alexey Kardashevskiy, Anshuman Khandual,
Benjamin Herrenschmidt, Christoph Hellwig, Michael Ellerman,
Mike Anderson, Paul Mackerras, Ram Pai, Anshuman Khandual,
Thiago Jung Bauermann
In-Reply-To: <20180824025933.24319-1-bauerman@linux.ibm.com>
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Ultravisor based secure guest platforms will use generic SWIOTLB DMA API
(i.e swiotlb_dma_ops structure) available under the CONFIG_DMA_DIRECT_OPS
config. Also base CONFIG_SWIOTLB needs to be explicitly selected as well.
Select both these config options on powerpc server platforms with secure
guest support.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
---
arch/powerpc/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index f786c962edf0..90f73d15f58a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -444,6 +444,8 @@ config PPC_SVM
bool "Secure virtual machine (SVM) support for POWERPC"
default n
depends on PPC_PSERIES
+ select DMA_DIRECT_OPS
+ select SWIOTLB
help
Support secure guests on POWERPC. There are certain POWER platforms
which support secure guests with the help of an Ultravisor executing
^ permalink raw reply related
* [RFC PATCH 01/11] powerpc/svm: Detect Secure Virtual Machine (SVM) platform
From: Thiago Jung Bauermann @ 2018-08-24 2:59 UTC (permalink / raw)
To: linuxppc-dev
Cc: iommu, linux-kernel, Alexey Kardashevskiy, Anshuman Khandual,
Benjamin Herrenschmidt, Christoph Hellwig, Michael Ellerman,
Mike Anderson, Paul Mackerras, Ram Pai, Anshuman Khandual,
Sukadev Bhattiprolu, Thiago Jung Bauermann
In-Reply-To: <20180824025933.24319-1-bauerman@linux.ibm.com>
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
A guest requests to be moved to secure memory early at the kernel
startup (in prom_init). Define a flag that can be easily checked by other
parts of the kernel so that they can set things up accordingly. This is
done by checking the MSR(S) bit, which is always set for secure VMs.
Also add a new config option CONFIG_PPC_SVM to wrap all these code to
prevent it from being executed from non subscribing platforms. This SVM
platform detection is applicable only to guest kernels that will run under
an Ultravisor as a secure guest.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
---
arch/powerpc/Kconfig | 11 +++++++++++
arch/powerpc/include/asm/reg.h | 3 +++
arch/powerpc/include/asm/svm.h | 22 ++++++++++++++++++++++
3 files changed, 36 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9f2b75fe2c2d..f786c962edf0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -440,6 +440,17 @@ config MATH_EMULATION_HW_UNIMPLEMENTED
endchoice
+config PPC_SVM
+ bool "Secure virtual machine (SVM) support for POWERPC"
+ default n
+ depends on PPC_PSERIES
+ help
+ Support secure guests on POWERPC. There are certain POWER platforms
+ which support secure guests with the help of an Ultravisor executing
+ below the hypervisor layer. This enables the support for those guests.
+
+ If unsure, say "N".
+
config PPC_TRANSACTIONAL_MEM
bool "Transactional Memory support for POWERPC"
depends on PPC_BOOK3S_64
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 562568414cf4..fcf7b79356d0 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -36,6 +36,7 @@
#define MSR_TM_LG 32 /* Trans Mem Available */
#define MSR_VEC_LG 25 /* Enable AltiVec */
#define MSR_VSX_LG 23 /* Enable VSX */
+#define MSR_S_LG 22 /* Secure VM bit */
#define MSR_POW_LG 18 /* Enable Power Management */
#define MSR_WE_LG 18 /* Wait State Enable */
#define MSR_TGPR_LG 17 /* TLB Update registers in use */
@@ -69,11 +70,13 @@
#define MSR_SF __MASK(MSR_SF_LG) /* Enable 64 bit mode */
#define MSR_ISF __MASK(MSR_ISF_LG) /* Interrupt 64b mode valid on 630 */
#define MSR_HV __MASK(MSR_HV_LG) /* Hypervisor state */
+#define MSR_S __MASK(MSR_S_LG) /* Secure state */
#else
/* so tests for these bits fail on 32-bit */
#define MSR_SF 0
#define MSR_ISF 0
#define MSR_HV 0
+#define MSR_S 0
#endif
/*
diff --git a/arch/powerpc/include/asm/svm.h b/arch/powerpc/include/asm/svm.h
new file mode 100644
index 000000000000..6f89e5d6d37f
--- /dev/null
+++ b/arch/powerpc/include/asm/svm.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * SVM helper functions
+ *
+ * Copyright 2018 Anshuman Khandual, IBM Corporation.
+ */
+
+#ifndef _ASM_POWERPC_SVM_H
+#define _ASM_POWERPC_SVM_H
+
+#ifdef CONFIG_PPC_SVM
+static bool is_svm_platform(void)
+{
+ return mfmsr() & MSR_S;
+}
+#else
+static inline bool is_svm_platform(void)
+{
+ return false;
+}
+#endif
+#endif /* _ASM_POWERPC_SVM_H */
^ permalink raw reply related
* [RFC PATCH 00/11] Secure Virtual Machine Enablement
From: Thiago Jung Bauermann @ 2018-08-24 2:59 UTC (permalink / raw)
To: linuxppc-dev
Cc: iommu, linux-kernel, Alexey Kardashevskiy, Anshuman Khandual,
Benjamin Herrenschmidt, Christoph Hellwig, Michael Ellerman,
Mike Anderson, Paul Mackerras, Ram Pai, Thiago Jung Bauermann
This series contains preliminary work to enable Secure Virtual Machines
(SVM) on powerpc. SVMs request to be migrated to secure memory very early in
the boot process (in prom_init()), so by default all of their memory is
inaccessible to the hypervisor. There is an ultravisor call that the VM can
use to request certain pages to be made accessible (aka shared).
The objective of these patches is to have the guest perform this request for
buffers that need to be shared with the hypervisor, such as the LPPACAs, the
SWIOTLB buffer and the Debug Trace Log. This work is incomplete: there are
surely other memory regions that need to be made accessible, but I'm posting
it early to get comments on whether the approach being taken is appropriate.
It should be applied on top of the generic virtio DMA API rework series
posted earlier, which adds a platform hook to override any arch based DMA
API operations for any virtio device:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-July/175994.html
I'm aware that changes need to be made to the patch series above, but IIUC
it depends on upcoming virtio cleanup from Christoph Hellwig so for now the
patch series above will be used as a stepping stone for this series.
This code has been tested with virtio block, net and scsi devices with and
without VIRTIO_F_IOMMU_PLATFORM flag. Please let me know what you think.
For now I am testing on a regular guest with a couple of patches on top
forcing is_svm_platform() to always return true and adding debug messages to
confirm that mem_convert_shared() is being called in the expected places.
These are the commands I'm using to start up the guest:
Without VIRTIO_F_IOMMU_PLATFORM:
qemu-system-ppc64 \
-enable-kvm \
-kernel /home/bauermann/src/linux/arch/powerpc/boot/zImage \
-append "root=PARTUUID=e550ad6f-05 ro" \
-machine pseries-2.6 \
-m 8G \
-smp 2 \
-serial mon:stdio \
-nographic \
-nodefaults \
-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 \
-drive file=/home/bauermann/VMs/svm.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 \
-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 \
-drive file=/home/bauermann/VMs/svm-blk.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 \
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \
-device virtio-net,netdev=hostnet0,id=net0,mac=52:54:00:96:70:1f \
-netdev user,id=hostnet0 \
-set netdev.hostnet0.hostfwd=tcp::42022-:22
With VIRTIO_F_IOMMU_PLATFORM. Same as above plus some -global options so
that the virtio devices use the modern interface rather than the
transitional one:
qemu-system-ppc64 \
-enable-kvm \
-kernel /home/bauermann/src/linux/arch/powerpc/boot/zImage \
-append "root=PARTUUID=e550ad6f-05 ro" \
-machine pseries-2.6 \
-m 8G \
-smp 2 \
-serial mon:stdio \
-nographic \
-nodefaults \
-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 \
-drive file=/home/bauermann/VMs/svm.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 \
-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 \
-drive file=/home/bauermann/VMs/svm-blk.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 \
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \
-device virtio-net,netdev=hostnet0,id=net0,mac=52:54:00:96:70:1f \
-netdev user,id=hostnet0 \
-set netdev.hostnet0.hostfwd=tcp::42022-:22 \
-global virtio-blk-pci.iommu_platform=true \
-global virtio-blk-pci.disable-legacy=on \
-global virtio-blk-pci.disable-modern=off \
-global virtio-net-pci.iommu_platform=true \
-global virtio-net-pci.disable-legacy=on \
-global virtio-net-pci.disable-modern=off \
-global virtio-scsi-pci.iommu_platform=true \
-global virtio-scsi-pci.disable-legacy=on \
-global virtio-scsi-pci.disable-modern=off
The code was tested with a couple of other permutations where one virtio
device has the flag VIRTIO_F_IOMMU_PLATFORM and others don't. Please suggest
some other scenarios which need to be tested as well.
Anshuman Khandual (10):
powerpc/svm: Detect Secure Virtual Machine (SVM) platform
powerpc/svm: Select CONFIG_DMA_DIRECT_OPS and CONFIG_SWIOTLB
powerpc/svm: Add memory conversion (shared/secure) helper functions
powerpc/svm: Convert SWIOTLB buffers to shared memory
powerpc/svm: Don't release SWIOTLB buffers on secure guests
powerpc/svm: Use SWIOTLB DMA API for all virtio devices
powerpc/svm: Use shared memory for Debug Trace Log (DTL)
powerpc/svm: Use shared memory for LPPACA structures
powerpc/svm: Force the use of bounce buffers
powerpc/svm: Increase SWIOTLB buffer size
Thiago Jung Bauermann (1):
powerpc: Add and use LPPACA_SIZE constant
arch/powerpc/Kconfig | 22 ++++++++
arch/powerpc/include/asm/mem_encrypt.h | 19 +++++++
arch/powerpc/include/asm/reg.h | 3 ++
arch/powerpc/include/asm/svm.h | 26 +++++++++
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/paca.c | 41 ++++++++++++--
arch/powerpc/kernel/svm.c | 99 ++++++++++++++++++++++++++++++++++
arch/powerpc/platforms/pseries/iommu.c | 6 ++-
arch/powerpc/platforms/pseries/setup.c | 5 +-
kernel/dma/swiotlb.c | 5 ++
10 files changed, 221 insertions(+), 6 deletions(-)
create mode 100644 arch/powerpc/include/asm/mem_encrypt.h
create mode 100644 arch/powerpc/include/asm/svm.h
create mode 100644 arch/powerpc/kernel/svm.c
^ permalink raw reply
* [PATCH v2] powerpc/xive: Avoid unitialized variable
From: Breno Leitao @ 2018-08-23 23:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mpe, clg, Breno Leitao
In-Reply-To: <3b8841ac-ebbb-523e-0d65-ebe27a702d3c@kaod.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 1417 bytes --]
From: Breno Leitao <breno.leitao@gmail.com>
Function xive_native_get_ipi() might uses chip_id without it being
initialized.
This gives the following error on 'smatch' tool:
error: uninitialized symbol 'chip_id'
The suggestion is using xc->chip_id instead of consulting the OF for chip id,
which is safe since xive_prepare_cpu() should have initialized ->chip_id by
the time xive_native_get_ipi() is called.
CC: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/sysdev/xive/native.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/native.c b/arch/powerpc/sysdev/xive/native.c
index 311185b9960a..bd90fd464a3a 100644
--- a/arch/powerpc/sysdev/xive/native.c
+++ b/arch/powerpc/sysdev/xive/native.c
@@ -238,20 +238,11 @@ static bool xive_native_match(struct device_node *node)
#ifdef CONFIG_SMP
static int xive_native_get_ipi(unsigned int cpu, struct xive_cpu *xc)
{
- struct device_node *np;
- unsigned int chip_id;
s64 irq;
- /* Find the chip ID */
- np = of_get_cpu_node(cpu, NULL);
- if (np) {
- if (of_property_read_u32(np, "ibm,chip-id", &chip_id) < 0)
- chip_id = 0;
- }
-
/* Allocate an IPI and populate info about it */
for (;;) {
- irq = opal_xive_allocate_irq(chip_id);
+ irq = opal_xive_allocate_irq(xc->chip_id);
if (irq == OPAL_BUSY) {
msleep(1);
continue;
--
2.17.1
^ permalink raw reply related
* Re: DT case sensitivity
From: Benjamin Herrenschmidt @ 2018-08-23 21:49 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Rob Herring, Stephen Rothwell, Grant Likely, Michael Ellerman,
Kumar Gala, David Gibson, Frank Rowand, devicetree-spec,
devicetree, linuxppc-dev
In-Reply-To: <20180823121929.GS24439@gate.crashing.org>
On Thu, 2018-08-23 at 07:19 -0500, Segher Boessenkool wrote:
> If one implementation does case insensitive, it will most likely just work,
> because people do not make insane names differing only in case on purpose.
Apple did :-)
ide, vs IDE, ata vs ATA, I've seen all sort of crap there, esp. on old
machines.
> Now people write other things that they only test against that implementation,
> and those things now only work with case-insensitive. And you do not know
> without testing if anything breaks. (But the laws of big numbers are against
> you here). Since there isn't really a drawback to doing case-insensitive
> always, that is a much safer way forward, much less work for everyone, even
> if technically the wrong thing to do :-)
>
>
> Segher
^ permalink raw reply
* [PATCH 2/2] soc: fsl: qbman: qman: avoid allocating from non existing gen_pool
From: Alexandre Belloni @ 2018-08-23 21:36 UTC (permalink / raw)
To: Li Yang
Cc: Roy Pledge, linuxppc-dev, linux-arm-kernel, linux-kernel,
Alexandre Belloni
In-Reply-To: <20180823213600.23426-1-alexandre.belloni@bootlin.com>
If the qman driver didn't probe, calling qman_alloc_fqid_range,
qman_alloc_pool_range or qman_alloc_cgrid_range (as done in dpaa_eth) will
pass a NULL pointer to gen_pool_alloc, leading to a NULL pointer
dereference.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
drivers/soc/fsl/qbman/qman.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index ecb22749df0b..8cc015183043 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -2729,6 +2729,9 @@ static int qman_alloc_range(struct gen_pool *p, u32 *result, u32 cnt)
{
unsigned long addr;
+ if (!p)
+ return -ENODEV;
+
addr = gen_pool_alloc(p, cnt);
if (!addr)
return -ENOMEM;
--
2.18.0
^ permalink raw reply related
* [PATCH 1/2] soc: fsl: qbman: qman_portal: defer probing when qman is not available
From: Alexandre Belloni @ 2018-08-23 21:35 UTC (permalink / raw)
To: Li Yang
Cc: Roy Pledge, linuxppc-dev, linux-arm-kernel, linux-kernel,
Alexandre Belloni
If the qman driver (qman_ccsr) doesn't probe or fail to probe before
qman_portal, qm_ccsr_start will be either NULL or a stale pointer to an
unmapped page.
This leads to a crash when probing qman_portal as the init_pcfg function
calls qman_liodn_fixup that tries to read qman registers.
Assume that qman didn't probe when the pool mask is 0.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
drivers/soc/fsl/qbman/qman_portal.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/fsl/qbman/qman_portal.c b/drivers/soc/fsl/qbman/qman_portal.c
index a120002b630e..4fc80d2c8feb 100644
--- a/drivers/soc/fsl/qbman/qman_portal.c
+++ b/drivers/soc/fsl/qbman/qman_portal.c
@@ -277,6 +277,8 @@ static int qman_portal_probe(struct platform_device *pdev)
}
pcfg->pools = qm_get_pools_sdqcr();
+ if (pcfg->pools == 0)
+ return -EPROBE_DEFER;
spin_lock(&qman_lock);
cpu = cpumask_next_zero(-1, &portal_cpus);
--
2.18.0
^ permalink raw reply related
* Re: [PATCH v2] crypto: vmx - Fix sleep-in-atomic bugs
From: Paulo Flabiano Smorigo @ 2018-08-23 20:34 UTC (permalink / raw)
To: Marcelo Henrique Cerri
Cc: Ondrej Mosnacek, Herbert Xu, linux-crypto, Stephan Mueller,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Leonidas S . Barbosa, linuxppc-dev, stable
In-Reply-To: <20180823000446.GA26297@gallifrey>
On 2018-08-22 21:04, Marcelo Henrique Cerri wrote:
> That looks good to me. Maybe Paulo can help testing it.
>
> --
> Regards,
> Marcelo
>
> On Wed, Aug 22, 2018 at 08:26:31AM +0200, Ondrej Mosnacek wrote:
>> This patch fixes sleep-in-atomic bugs in AES-CBC and AES-XTS VMX
>> implementations. The problem is that the blkcipher_* functions should
>> not be called in atomic context.
>>
>> The bugs can be reproduced via the AF_ALG interface by trying to
>> encrypt/decrypt sufficiently large buffers (at least 64 KiB) using the
>> VMX implementations of 'cbc(aes)' or 'xts(aes)'. Such operations then
>> trigger BUG in crypto_yield():
>>
>> [ 891.863680] BUG: sleeping function called from invalid context at
>> include/crypto/algapi.h:424
>> [ 891.864622] in_atomic(): 1, irqs_disabled(): 0, pid: 12347, name:
>> kcapi-enc
>> [ 891.864739] 1 lock held by kcapi-enc/12347:
>> [ 891.864811] #0: 00000000f5d42c46 (sk_lock-AF_ALG){+.+.}, at:
>> skcipher_recvmsg+0x50/0x530
>> [ 891.865076] CPU: 5 PID: 12347 Comm: kcapi-enc Not tainted
>> 4.19.0-0.rc0.git3.1.fc30.ppc64le #1
>> [ 891.865251] Call Trace:
>> [ 891.865340] [c0000003387578c0] [c000000000d67ea4]
>> dump_stack+0xe8/0x164 (unreliable)
>> [ 891.865511] [c000000338757910] [c000000000172a58]
>> ___might_sleep+0x2f8/0x310
>> [ 891.865679] [c000000338757990] [c0000000006bff74]
>> blkcipher_walk_done+0x374/0x4a0
>> [ 891.865825] [c0000003387579e0] [d000000007e73e70]
>> p8_aes_cbc_encrypt+0x1c8/0x260 [vmx_crypto]
>> [ 891.865993] [c000000338757ad0] [c0000000006c0ee0]
>> skcipher_encrypt_blkcipher+0x60/0x80
>> [ 891.866128] [c000000338757b10] [c0000000006ec504]
>> skcipher_recvmsg+0x424/0x530
>> [ 891.866283] [c000000338757bd0] [c000000000b00654]
>> sock_recvmsg+0x74/0xa0
>> [ 891.866403] [c000000338757c10] [c000000000b00f64]
>> ___sys_recvmsg+0xf4/0x2f0
>> [ 891.866515] [c000000338757d90] [c000000000b02bb8]
>> __sys_recvmsg+0x68/0xe0
>> [ 891.866631] [c000000338757e30] [c00000000000bbe4]
>> system_call+0x5c/0x70
>>
>> Fixes: 8c755ace357c ("crypto: vmx - Adding CBC routines for VMX
>> module")
>> Fixes: c07f5d3da643 ("crypto: vmx - Adding support for XTS")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
>> ---
>> Still untested, please test and review if possible.
>>
>> Changes in v2:
>> - fix leaving preemtption, etc. disabled when leaving the function
>> (I switched to the more obvious and less efficient variant for the
>> sake of clarity.)
>>
>> drivers/crypto/vmx/aes_cbc.c | 30 ++++++++++++++----------------
>> drivers/crypto/vmx/aes_xts.c | 21 ++++++++++++++-------
>> 2 files changed, 28 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/crypto/vmx/aes_cbc.c
>> b/drivers/crypto/vmx/aes_cbc.c
>> index 5285ece4f33a..b71895871be3 100644
>> --- a/drivers/crypto/vmx/aes_cbc.c
>> +++ b/drivers/crypto/vmx/aes_cbc.c
>> @@ -107,24 +107,23 @@ static int p8_aes_cbc_encrypt(struct
>> blkcipher_desc *desc,
>> ret = crypto_skcipher_encrypt(req);
>> skcipher_request_zero(req);
>> } else {
>> - preempt_disable();
>> - pagefault_disable();
>> - enable_kernel_vsx();
>> -
>> blkcipher_walk_init(&walk, dst, src, nbytes);
>> ret = blkcipher_walk_virt(desc, &walk);
>> while ((nbytes = walk.nbytes)) {
>> + preempt_disable();
>> + pagefault_disable();
>> + enable_kernel_vsx();
>> aes_p8_cbc_encrypt(walk.src.virt.addr,
>> walk.dst.virt.addr,
>> nbytes & AES_BLOCK_MASK,
>> &ctx->enc_key, walk.iv, 1);
>> + disable_kernel_vsx();
>> + pagefault_enable();
>> + preempt_enable();
>> +
>> nbytes &= AES_BLOCK_SIZE - 1;
>> ret = blkcipher_walk_done(desc, &walk, nbytes);
>> }
>> -
>> - disable_kernel_vsx();
>> - pagefault_enable();
>> - preempt_enable();
>> }
>>
>> return ret;
>> @@ -147,24 +146,23 @@ static int p8_aes_cbc_decrypt(struct
>> blkcipher_desc *desc,
>> ret = crypto_skcipher_decrypt(req);
>> skcipher_request_zero(req);
>> } else {
>> - preempt_disable();
>> - pagefault_disable();
>> - enable_kernel_vsx();
>> -
>> blkcipher_walk_init(&walk, dst, src, nbytes);
>> ret = blkcipher_walk_virt(desc, &walk);
>> while ((nbytes = walk.nbytes)) {
>> + preempt_disable();
>> + pagefault_disable();
>> + enable_kernel_vsx();
>> aes_p8_cbc_encrypt(walk.src.virt.addr,
>> walk.dst.virt.addr,
>> nbytes & AES_BLOCK_MASK,
>> &ctx->dec_key, walk.iv, 0);
>> + disable_kernel_vsx();
>> + pagefault_enable();
>> + preempt_enable();
>> +
>> nbytes &= AES_BLOCK_SIZE - 1;
>> ret = blkcipher_walk_done(desc, &walk, nbytes);
>> }
>> -
>> - disable_kernel_vsx();
>> - pagefault_enable();
>> - preempt_enable();
>> }
>>
>> return ret;
>> diff --git a/drivers/crypto/vmx/aes_xts.c
>> b/drivers/crypto/vmx/aes_xts.c
>> index 8bd9aff0f55f..e9954a7d4694 100644
>> --- a/drivers/crypto/vmx/aes_xts.c
>> +++ b/drivers/crypto/vmx/aes_xts.c
>> @@ -116,32 +116,39 @@ static int p8_aes_xts_crypt(struct
>> blkcipher_desc *desc,
>> ret = enc? crypto_skcipher_encrypt(req) :
>> crypto_skcipher_decrypt(req);
>> skcipher_request_zero(req);
>> } else {
>> + blkcipher_walk_init(&walk, dst, src, nbytes);
>> +
>> + ret = blkcipher_walk_virt(desc, &walk);
>> +
>> preempt_disable();
>> pagefault_disable();
>> enable_kernel_vsx();
>>
>> - blkcipher_walk_init(&walk, dst, src, nbytes);
>> -
>> - ret = blkcipher_walk_virt(desc, &walk);
>> iv = walk.iv;
>> memset(tweak, 0, AES_BLOCK_SIZE);
>> aes_p8_encrypt(iv, tweak, &ctx->tweak_key);
>>
>> + disable_kernel_vsx();
>> + pagefault_enable();
>> + preempt_enable();
>> +
>> while ((nbytes = walk.nbytes)) {
>> + preempt_disable();
>> + pagefault_disable();
>> + enable_kernel_vsx();
>> if (enc)
>> aes_p8_xts_encrypt(walk.src.virt.addr, walk.dst.virt.addr,
>> nbytes & AES_BLOCK_MASK, &ctx->enc_key, NULL, tweak);
>> else
>> aes_p8_xts_decrypt(walk.src.virt.addr, walk.dst.virt.addr,
>> nbytes & AES_BLOCK_MASK, &ctx->dec_key, NULL, tweak);
>> + disable_kernel_vsx();
>> + pagefault_enable();
>> + preempt_enable();
>>
>> nbytes &= AES_BLOCK_SIZE - 1;
>> ret = blkcipher_walk_done(desc, &walk, nbytes);
>> }
>> -
>> - disable_kernel_vsx();
>> - pagefault_enable();
>> - preempt_enable();
>> }
>> return ret;
>> }
>> --
>> 2.17.1
>>
Sure thing. I'll test it later today. Thanks Ondrej for the fix.
--
Paulo Flabiano Smorigo
IBM Linux Technology Center
^ permalink raw reply
* RE: [PATCH 5/5] arm64: dts: add LX2160ARDB board support
From: Vabhav Sharma @ 2018-08-23 15:08 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Mark Rutland, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Michael Turquette, Stephen Boyd, Rafael J. Wysocki, Viresh Kumar,
linux-clk, open list:THERMAL, linux-kernel-owner@vger.kernel.org,
Catalin Marinas, Will Deacon, Greg Kroah-Hartman, Arnd Bergmann,
Kate Stewart, Masahiro Yamada, Russell King, Varun Sethi,
Udit Kumar, Priyanka Jain, Sriram Dash
In-Reply-To: <CAL_JsqKH4haGy2F2_2EP=evC8ip7DmGR8J4wzrO0wWnOLsaZqA@mail.gmail.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iIEhlcnJpbmcgPHJv
YmgrZHRAa2VybmVsLm9yZz4NCj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjIsIDIwMTggMjox
NSBBTQ0KPiBUbzogVmFiaGF2IFNoYXJtYSA8dmFiaGF2LnNoYXJtYUBueHAuY29tPg0KPiBDYzog
bGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7
IE1hcmsgUnV0bGFuZA0KPiA8bWFyay5ydXRsYW5kQGFybS5jb20+OyBsaW51eHBwYy1kZXYgPGxp
bnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnPjsNCj4gbW9kZXJhdGVkIGxpc3Q6QVJNL0ZSRUVT
Q0FMRSBJTVggLyBNWEMgQVJNIEFSQ0hJVEVDVFVSRSA8bGludXgtYXJtLQ0KPiBrZXJuZWxAbGlz
dHMuaW5mcmFkZWFkLm9yZz47IE1pY2hhZWwgVHVycXVldHRlIDxtdHVycXVldHRlQGJheWxpYnJl
LmNvbT47DQo+IFN0ZXBoZW4gQm95ZCA8c2JveWRAa2VybmVsLm9yZz47IFJhZmFlbCBKLiBXeXNv
Y2tpIDxyandAcmp3eXNvY2tpLm5ldD47DQo+IFZpcmVzaCBLdW1hciA8dmlyZXNoLmt1bWFyQGxp
bmFyby5vcmc+OyBsaW51eC1jbGsgPGxpbnV4LQ0KPiBjbGtAdmdlci5rZXJuZWwub3JnPjsgb3Bl
biBsaXN0OlRIRVJNQUwgPGxpbnV4LXBtQHZnZXIua2VybmVsLm9yZz47IGxpbnV4LQ0KPiBrZXJu
ZWwtb3duZXJAdmdlci5rZXJuZWwub3JnOyBDYXRhbGluIE1hcmluYXMgPGNhdGFsaW4ubWFyaW5h
c0Bhcm0uY29tPjsNCj4gV2lsbCBEZWFjb24gPHdpbGwuZGVhY29uQGFybS5jb20+OyBHcmVnIEty
b2FoLUhhcnRtYW4NCj4gPGdyZWdraEBsaW51eGZvdW5kYXRpb24ub3JnPjsgQXJuZCBCZXJnbWFu
biA8YXJuZEBhcm5kYi5kZT47IEthdGUNCj4gU3Rld2FydCA8a3N0ZXdhcnRAbGludXhmb3VuZGF0
aW9uLm9yZz47IE1hc2FoaXJvIFlhbWFkYQ0KPiA8eWFtYWRhLm1hc2FoaXJvQHNvY2lvbmV4dC5j
b20+OyBSdXNzZWxsIEtpbmcgPGxpbnV4QGFybWxpbnV4Lm9yZy51az47DQo+IFZhcnVuIFNldGhp
IDxWLlNldGhpQG54cC5jb20+OyBVZGl0IEt1bWFyIDx1ZGl0Lmt1bWFyQG54cC5jb20+Ow0KPiBQ
cml5YW5rYSBKYWluIDxwcml5YW5rYS5qYWluQG54cC5jb20+OyBTcmlyYW0gRGFzaA0KPiA8c3Jp
cmFtLmRhc2hAbnhwLmNvbT4NCj4gU3ViamVjdDogUmU6IFtQQVRDSCA1LzVdIGFybTY0OiBkdHM6
IGFkZCBMWDIxNjBBUkRCIGJvYXJkIHN1cHBvcnQNCj4gDQo+IE9uIE1vbiwgQXVnIDIwLCAyMDE4
IGF0IDE6NTIgUE0gVmFiaGF2IFNoYXJtYQ0KPiA8dmFiaGF2LnNoYXJtYUBueHAuY29tPiB3cm90
ZToNCj4gPg0KPiA+IExYMjE2MEEgcmVmZXJlbmNlIGRlc2lnbiBib2FyZCAoUkRCKSBpcyBhIGhp
Z2gtcGVyZm9ybWFuY2UgY29tcHV0aW5nLA0KPiA+IGV2YWx1YXRpb24sIGFuZCBkZXZlbG9wbWVu
dCBwbGF0Zm9ybSB3aXRoIExYMjE2MEEgU29DLg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogUHJp
eWFua2EgSmFpbiA8cHJpeWFua2EuamFpbkBueHAuY29tPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFNy
aXJhbSBEYXNoIDxzcmlyYW0uZGFzaEBueHAuY29tPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFZhYmhh
diBTaGFybWEgPHZhYmhhdi5zaGFybWFAbnhwLmNvbT4NCj4gPiAtLS0NCj4gPiAgYXJjaC9hcm02
NC9ib290L2R0cy9mcmVlc2NhbGUvTWFrZWZpbGUgICAgICAgICAgICB8ICAxICsNCj4gPiAgYXJj
aC9hcm02NC9ib290L2R0cy9mcmVlc2NhbGUvZnNsLWx4MjE2MGEtcmRiLmR0cyB8IDk1DQo+ID4g
KysrKysrKysrKysrKysrKysrKysrKysNCj4gPiAgMiBmaWxlcyBjaGFuZ2VkLCA5NiBpbnNlcnRp
b25zKCspDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBhcmNoL2FybTY0L2Jvb3QvZHRzL2ZyZWVz
Y2FsZS9mc2wtbHgyMTYwYS1yZGIuZHRzDQo+ID4NCj4gPiBkaWZmIC0tZ2l0IGEvYXJjaC9hcm02
NC9ib290L2R0cy9mcmVlc2NhbGUvTWFrZWZpbGUNCj4gPiBiL2FyY2gvYXJtNjQvYm9vdC9kdHMv
ZnJlZXNjYWxlL01ha2VmaWxlDQo+ID4gaW5kZXggODZlMThhZC4uNDQ1YjcyYiAxMDA2NDQNCj4g
PiAtLS0gYS9hcmNoL2FybTY0L2Jvb3QvZHRzL2ZyZWVzY2FsZS9NYWtlZmlsZQ0KPiA+ICsrKyBi
L2FyY2gvYXJtNjQvYm9vdC9kdHMvZnJlZXNjYWxlL01ha2VmaWxlDQo+ID4gQEAgLTEzLDMgKzEz
LDQgQEAgZHRiLSQoQ09ORklHX0FSQ0hfTEFZRVJTQ0FQRSkgKz0gZnNsLWxzMjA4MGEtDQo+IHJk
Yi5kdGINCj4gPiAgZHRiLSQoQ09ORklHX0FSQ0hfTEFZRVJTQ0FQRSkgKz0gZnNsLWxzMjA4MGEt
c2ltdS5kdGINCj4gPiAgZHRiLSQoQ09ORklHX0FSQ0hfTEFZRVJTQ0FQRSkgKz0gZnNsLWxzMjA4
OGEtcWRzLmR0Yg0KPiA+ICBkdGItJChDT05GSUdfQVJDSF9MQVlFUlNDQVBFKSArPSBmc2wtbHMy
MDg4YS1yZGIuZHRiDQo+ID4gK2R0Yi0kKENPTkZJR19BUkNIX0xBWUVSU0NBUEUpICs9IGZzbC1s
eDIxNjBhLXJkYi5kdGINCj4gPiBkaWZmIC0tZ2l0IGEvYXJjaC9hcm02NC9ib290L2R0cy9mcmVl
c2NhbGUvZnNsLWx4MjE2MGEtcmRiLmR0cw0KPiA+IGIvYXJjaC9hcm02NC9ib290L2R0cy9mcmVl
c2NhbGUvZnNsLWx4MjE2MGEtcmRiLmR0cw0KPiA+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0DQo+ID4g
aW5kZXggMDAwMDAwMC4uNzBmYWQyMA0KPiA+IC0tLSAvZGV2L251bGwNCj4gPiArKysgYi9hcmNo
L2FybTY0L2Jvb3QvZHRzL2ZyZWVzY2FsZS9mc2wtbHgyMTYwYS1yZGIuZHRzDQo+ID4gQEAgLTAs
MCArMSw5NSBAQA0KPiA+ICsvLyBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogKEdQTC0yLjAgT1Ig
TUlUKSAvLyAvLyBEZXZpY2UgVHJlZSBmaWxlDQo+ID4gK2ZvciBMWDIxNjBBUkRCIC8vIC8vIENv
cHlyaWdodCAyMDE4IE5YUA0KPiA+ICsNCj4gPiArL2R0cy12MS87DQo+ID4gKw0KPiA+ICsjaW5j
bHVkZSAiZnNsLWx4MjE2MGEuZHRzaSINCj4gPiArDQo+ID4gKy8gew0KPiA+ICsgICAgICAgbW9k
ZWwgPSAiTlhQIExheWVyc2NhcGUgTFgyMTYwQVJEQiI7DQo+ID4gKyAgICAgICBjb21wYXRpYmxl
ID0gImZzbCxseDIxNjBhLXJkYiIsICJmc2wsbHgyMTYwYSI7DQo+ID4gKw0KPiA+ICsgICAgICAg
YWxpYXNlcyB7DQo+ID4gKyAgICAgICAgICAgICAgIGNyeXB0byA9ICZjcnlwdG87DQo+IA0KPiBE
cm9wIHRoaXMuIEFsaWFzZXMgc2hvdWxkIGJlIG51bWJlcmVkLCBhbmQgdGhpcyBpcyBub3QgYSBz
dGFuZGFyZCBhbGlhcyBuYW1lDQo+IGVpdGhlci4NCk9rDQo+IA0KPiA+ICsgICAgICAgICAgICAg
ICBzZXJpYWwwID0gJnVhcnQwOw0KPiA+ICsgICAgICAgICAgICAgICBzZXJpYWwxID0gJnVhcnQx
Ow0KPiA+ICsgICAgICAgICAgICAgICBzZXJpYWwyID0gJnVhcnQyOw0KPiA+ICsgICAgICAgICAg
ICAgICBzZXJpYWwzID0gJnVhcnQzOw0KPiA+ICsgICAgICAgfTsNCj4gPiArICAgICAgIGNob3Nl
biB7DQo+ID4gKyAgICAgICAgICAgICAgIHN0ZG91dC1wYXRoID0gInNlcmlhbDA6MTE1MjAwbjgi
Ow0KPiA+ICsgICAgICAgfTsNCj4gPiArfTsNCj4gPiArDQo+ID4gKyZ1YXJ0MCB7DQo+ID4gKyAg
ICAgICBzdGF0dXMgPSAib2theSI7DQo+ID4gK307DQo+ID4gKw0KPiA+ICsmdWFydDEgew0KPiA+
ICsgICAgICAgc3RhdHVzID0gIm9rYXkiOw0KPiA+ICt9Ow0KPiA+ICsNCj4gPiArJmkyYzAgew0K
PiA+ICsgICAgICAgc3RhdHVzID0gIm9rYXkiOw0KPiA+ICsgICAgICAgcGNhOTU0N0A3NyB7DQo+
IA0KPiBpMmMtbXV4QDc3DQpTdXJlDQo+IA0KPiA+ICsgICAgICAgICAgICAgICBjb21wYXRpYmxl
ID0gIm54cCxwY2E5NTQ3IjsNCj4gPiArICAgICAgICAgICAgICAgcmVnID0gPDB4Nzc+Ow0KPiA+
ICsgICAgICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwxPjsNCj4gPiArICAgICAgICAgICAg
ICAgI3NpemUtY2VsbHMgPSA8MD47DQo+ID4gKw0KPiA+ICsgICAgICAgICAgICAgICBpMmNAMiB7
DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8MT47DQo+ID4g
KyAgICAgICAgICAgICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8MD47DQo+ID4gKyAgICAgICAg
ICAgICAgICAgICAgICAgcmVnID0gPDB4Mj47DQo+ID4gKw0KPiA+ICsgICAgICAgICAgICAgICAg
ICAgICAgIGluYTIyMEA0MCB7DQpwb3dlci1zZW5zb3JANDANCj4gPiArICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAidGksaW5hMjIwIjsNCj4gPiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDQwPjsNCj4gPiArICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHNodW50LXJlc2lzdG9yID0gPDEwMDA+Ow0KPiA+ICsgICAgICAgICAg
ICAgICAgICAgICAgIH07DQo+ID4gKyAgICAgICAgICAgICAgIH07DQo+ID4gKw0KPiA+ICsgICAg
ICAgICAgICAgICBpMmNAMyB7DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgI2FkZHJlc3Mt
Y2VsbHMgPSA8MT47DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8
MD47DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgcmVnID0gPDB4Mz47DQo+ID4gKw0KPiA+
ICsgICAgICAgICAgICAgICAgICAgICAgIHNhNTYwMDRANGMgew0KPiANCj4gdGVtcGVyYXR1cmUt
c2Vuc29yQDRjDQpPaywgdGVtcGVyYXR1cmUtc2Vuc29yLTFANGMNCj4gDQo+ID4gKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gIm54cCxzYTU2MDA0IjsNCj4gPiAr
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDRjPjsNCj4gPiArICAgICAg
ICAgICAgICAgICAgICAgICB9Ow0KPiA+ICsNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICBz
YTU2MDA0QDRkIHsNCk9rLHRlbXBlcmF0dXJlLXNlbnNvci0yQDRkDQo+ID4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gIm54cCxzYTU2MDA0IjsNCj4gPiArICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDRkPjsNCj4gPiArICAgICAgICAg
ICAgICAgICAgICAgICB9Ow0KPiA+ICsgICAgICAgICAgICAgICB9Ow0KPiA+ICsgICAgICAgfTsN
Cj4gPiArfTsNCj4gPiArDQo+ID4gKyZpMmM0IHsNCj4gPiArICAgICAgIHN0YXR1cyA9ICJva2F5
IjsNCj4gPiArDQo+ID4gKyAgICAgICBydGNANTEgew0KPiA+ICsgICAgICAgICAgICAgICBjb21w
YXRpYmxlID0gIm54cCxwY2YyMTI5IjsNCj4gPiArICAgICAgICAgICAgICAgcmVnID0gPDB4NTE+
Ow0KPiA+ICsgICAgICAgICAgICAgICAvLyBJUlExMF9CDQo+ID4gKyAgICAgICAgICAgICAgIGlu
dGVycnVwdHMgPSA8MCAxNTAgMHg0PjsNCj4gPiArICAgICAgICAgICAgICAgfTsNCj4gPiArDQo+
ID4gK307DQo+ID4gKw0KPiA+ICsmdXNiMCB7DQo+ID4gKyAgICAgICBzdGF0dXMgPSAib2theSI7
DQo+ID4gK307DQo+ID4gKw0KPiA+ICsmdXNiMSB7DQo+ID4gKyAgICAgICBzdGF0dXMgPSAib2th
eSI7DQo+ID4gK307DQo+ID4gKw0KPiA+ICsmY3J5cHRvIHsNCj4gPiArICAgICAgIHN0YXR1cyA9
ICJva2F5IjsNCj4gPiArfTsNCj4gPiAtLQ0KPiA+IDIuNy40DQo+ID4NCg==
^ permalink raw reply
* RE: [PATCH 4/5] arm64: dts: add QorIQ LX2160A SoC support
From: Vabhav Sharma @ 2018-08-23 15:00 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
robh+dt@kernel.org, mark.rutland@arm.com,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, mturquette@baylibre.com,
sboyd@kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org,
linux-clk@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel-owner@vger.kernel.org, catalin.marinas@arm.com,
will.deacon@arm.com, gregkh@linuxfoundation.org, arnd@arndb.de,
kstewart@linuxfoundation.org, yamada.masahiro@socionext.com,
linux@armlinux.org.uk, Varun Sethi, Udit Kumar, Ramneek Mehresh,
Ying Zhang, Nipun Gupta, Priyanka Jain, Yogesh Narayan Gaur,
Sriram Dash
In-Reply-To: <20180821101652.GA18139@e107155-lin>
> -----Original Message-----
> From: Sudeep Holla <sudeep.holla@arm.com>
> Sent: Tuesday, August 21, 2018 3:47 PM
> To: Vabhav Sharma <vabhav.sharma@nxp.com>
> Cc: linux-kernel@vger.kernel.org; devicetree@vger.kernel.org;
> robh+dt@kernel.org; mark.rutland@arm.com; linuxppc-dev@lists.ozlabs.org;
> linux-arm-kernel@lists.infradead.org; mturquette@baylibre.com;
> sboyd@kernel.org; rjw@rjwysocki.net; viresh.kumar@linaro.org; linux-
> clk@vger.kernel.org; linux-pm@vger.kernel.org; linux-kernel-
> owner@vger.kernel.org; catalin.marinas@arm.com; will.deacon@arm.com;
> gregkh@linuxfoundation.org; arnd@arndb.de;
> kstewart@linuxfoundation.org; yamada.masahiro@socionext.com;
> linux@armlinux.org.uk; Varun Sethi <V.Sethi@nxp.com>; Udit Kumar
> <udit.kumar@nxp.com>; Ramneek Mehresh <ramneek.mehresh@nxp.com>;
> Ying Zhang <ying.zhang22455@nxp.com>; Nipun Gupta
> <nipun.gupta@nxp.com>; Priyanka Jain <priyanka.jain@nxp.com>; Yogesh
> Narayan Gaur <yogeshnarayan.gaur@nxp.com>; Sriram Dash
> <sriram.dash@nxp.com>; Sudeep Holla <sudeep.holla@arm.com>
> Subject: Re: [PATCH 4/5] arm64: dts: add QorIQ LX2160A SoC support
>=20
> On Mon, Aug 20, 2018 at 12:17:15PM +0530, Vabhav Sharma wrote:
> > LX2160A SoC is based on Layerscape Chassis Generation 3.2 Architecture.
> >
> > LX2160A features an advanced 16 64-bit ARM v8 CortexA72 processor
> > cores in 8 cluster, CCN508, GICv3,two 64-bit DDR4 memory controller, 8
> > I2C controllers, 3 dspi, 2 esdhc,2 USB 3.0, mmu 500, 3 SATA, 4 PL011
> > SBSA UARTs etc.
> >
> > Signed-off-by: Ramneek Mehresh <ramneek.mehresh@nxp.com>
> > Signed-off-by: Zhang Ying-22455 <ying.zhang22455@nxp.com>
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> > Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
> > Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
> > ---
> > arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 572
> > +++++++++++++++++++++++++
> > 1 file changed, 572 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > new file mode 100644
> > index 0000000..e35e494
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > @@ -0,0 +1,572 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT) // // Device Tree
> > +Include file for Layerscape-LX2160A family SoC.
> > +//
> > +// Copyright 2018 NXP
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/memreserve/ 0x80000000 0x00010000;
> > +
> > +/ {
> > + compatible =3D "fsl,lx2160a";
> > + interrupt-parent =3D <&gic>;
> > + #address-cells =3D <2>;
> > + #size-cells =3D <2>;
> > +
> > + cpus {
> > + #address-cells =3D <1>;
> > + #size-cells =3D <0>;
> > +
> > + // 8 clusters having 2 Cortex-A72 cores each
> > + cpu@0 {
> > + device_type =3D "cpu";
> > + compatible =3D "arm,cortex-a72";
> > + reg =3D <0x0>;
> > + clocks =3D <&clockgen 1 0>;
> > + next-level-cache =3D <&cluster0_l2>;
>=20
> If you expect to get cache properties in sysfs entries, you need to popul=
ate
> them here and for each L2 cache.
Rather sysfs, If Entry is not present then print "cacheinfo: Unable to det=
ect cache hierarchy for CPU 0" appears in boot log which is bad saying some=
thing is not present.
Either this print is require change to debug instead of warning.
>=20
> [...]
>=20
> > +
> > + rstcr: syscon@1e60000 {
> > + compatible =3D "syscon";
> > + reg =3D <0x0 0x1e60000 0x0 0x4>;
> > + };
> > +
> > + reboot {
> > + compatible =3D"syscon-reboot";
> > + regmap =3D <&rstcr>;
> > + offset =3D <0x0>;
> > + mask =3D <0x2>;
>=20
> Is this disabled in bootloader ? With PSCI, it's preferred to use
> SYSTEM_RESET/OFF. EL3 f/w may need to do some housekeeping on
> poweroff.
No, PSCIv0.2 is used and control passes to EL3 fw via smc call, psci node i=
s present in the file.
This node is not required and keeping it in case PSCI is not used.
>=20
> > + };
> > +
> > + timer {
> > + compatible =3D "arm,armv8-timer";
> > + interrupts =3D <1 13 4>, // Physical Secure PPI, active-low
>=20
> The comment says active low but the value 4 indicates it's HIGH from
> "include/dt-bindings/interrupt-controller/irq.h"
Thanks, I will change the entries to existing definition IRQ_TYPE_LEVEL_LOW=
,GIC_PPI which is self-explanatory and not require comments
>=20
> > + <1 14 4>, // Physical Non-Secure PPI, active-low
> > + <1 11 4>, // Virtual PPI, active-low
> > + <1 10 4>; // Hypervisor PPI, active-low
> > + };
> > +
> > + pmu {
> > + compatible =3D "arm,armv8-pmuv3";
>=20
> More specific compatible preferably "arm,cortex-a72-pmu" ?
Sure.
>=20
> --
> Regards,
> Sudeep
^ permalink raw reply
* Re: [PATCH v2 3/4] powerpc/mm: fix a warning when a cache is common to PGD and hugepages
From: Christophe LEROY @ 2018-08-23 14:50 UTC (permalink / raw)
To: Segher Boessenkool, Michael Ellerman, aneesh.kumar
Cc: Andrew Donnellan, Russell Currey, Aneesh Kumar K.V,
Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev,
linux-kernel
In-Reply-To: <20180823144118.GU24439@gate.crashing.org>
Le 23/08/2018 à 16:41, Segher Boessenkool a écrit :
> On Thu, Aug 23, 2018 at 11:32:16PM +1000, Andrew Donnellan wrote:
>> On 23/08/18 21:56, Michael Ellerman wrote:
>>> Christophe LEROY <christophe.leroy@c-s.fr> writes:
>>>
>>>> Le 23/08/2018 à 12:36, Segher Boessenkool a écrit :
>>>>> On Thu, Aug 23, 2018 at 11:40:22AM +0200, Christophe LEROY wrote:
>>>>>> The only small problème I have is that some version of GCC seems to
>>>>>> complain about big memset() (132k and 256k ones). Is there a way to tell
>>>>>> GCC we really want to do it ?
>>>>>
>>>>> I'm not sure what you mean. Complain, is that a warning, is that an
>>>>> error?
>>>>> What does it say? Do you have some example code to reproduce it? Etc.
>>>>
>>>> I saw the warnings in the checks at
>>>> https://patchwork.ozlabs.org/patch/957566/
>>>> Unfortunatly the link is now broken.
>>>
>>> ruscur/ajd any idea what happened to the snowpatch links here?
>>
>> I think they've disappeared because our log rotation is too fast - I've
>> now upped it to 30 days. I guess over time we'll figure out what we need
>> in this regard, ideally we'd keep logs indefinitely but they're several
>> megs per build.
>>
>> I've kicked off another build for this series and the links in Patchwork
>> should update to point to the new job when it's done (probably in the
>> next couple of hours).
>
> It's back, thanks Andrew!
>
> The warnings are not from GCC at all: the warnings are from sparse.
Oh, ok, my mistake, I reminded seeing those warnings without paying much
attention to them at that time.
Anyway, should we do anything about this warning ? If so, what
could/should be done ?
Christophe
^ permalink raw reply
* Re: [PATCH v2 3/4] powerpc/mm: fix a warning when a cache is common to PGD and hugepages
From: Segher Boessenkool @ 2018-08-23 14:41 UTC (permalink / raw)
To: Andrew Donnellan
Cc: Michael Ellerman, Russell Currey, Aneesh Kumar K.V,
Benjamin Herrenschmidt, Paul Mackerras, aneesh.kumar,
linuxppc-dev, linux-kernel, Christophe LEROY
In-Reply-To: <d561e11b-b85e-6f6c-0936-4a93cf309915@au1.ibm.com>
On Thu, Aug 23, 2018 at 11:32:16PM +1000, Andrew Donnellan wrote:
> On 23/08/18 21:56, Michael Ellerman wrote:
> >Christophe LEROY <christophe.leroy@c-s.fr> writes:
> >
> >>Le 23/08/2018 à 12:36, Segher Boessenkool a écrit :
> >>>On Thu, Aug 23, 2018 at 11:40:22AM +0200, Christophe LEROY wrote:
> >>>>The only small problème I have is that some version of GCC seems to
> >>>>complain about big memset() (132k and 256k ones). Is there a way to tell
> >>>>GCC we really want to do it ?
> >>>
> >>>I'm not sure what you mean. Complain, is that a warning, is that an
> >>>error?
> >>>What does it say? Do you have some example code to reproduce it? Etc.
> >>
> >>I saw the warnings in the checks at
> >>https://patchwork.ozlabs.org/patch/957566/
> >>Unfortunatly the link is now broken.
> >
> >ruscur/ajd any idea what happened to the snowpatch links here?
>
> I think they've disappeared because our log rotation is too fast - I've
> now upped it to 30 days. I guess over time we'll figure out what we need
> in this regard, ideally we'd keep logs indefinitely but they're several
> megs per build.
>
> I've kicked off another build for this series and the links in Patchwork
> should update to point to the new job when it's done (probably in the
> next couple of hours).
It's back, thanks Andrew!
The warnings are not from GCC at all: the warnings are from sparse.
Segher
^ permalink raw reply
* Re: [v2] poewrpc/mce: Fix SLB rebolting during MCE recovery path.
From: Michael Ellerman @ 2018-08-23 14:18 UTC (permalink / raw)
To: Mahesh J Salgaonkar, linuxppc-dev; +Cc: Aneesh Kumar K.V, Nicholas Piggin
In-Reply-To: <153500011126.9482.8367068862900987587.stgit@jupiter.in.ibm.com>
On Thu, 2018-08-23 at 04:56:08 UTC, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> With the powrpc next commit e7e81847478 (poewrpc/mce: Fix SLB rebolting
> during MCE recovery path.), the SLB error recovery is broken. The new
> change now does not add index value to RB[52-63] that selects the SLB
> entry while rebolting, instead it assumes that the shadow save area
> already have index embeded correctly in esid field. While all valid bolted
> save areas do contain index value set correctly, there is a case where
> 3rd (KSTACK_INDEX) entry for kernel stack does not embed index for NULL
> esid entry. This patch fixes that.
>
> Without this patch the SLB rebolt code overwirtes the 1st entry of kernel
> linear mapping and causes SLB recovery to fail.
>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0f52b3a00c789569d7ed822b5a6b30
cheers
^ permalink raw reply
* Re: KVM: PPC: Book3S: Fix guest DMA when guest partially backed by THP pages
From: Michael Ellerman @ 2018-08-23 14:18 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev, kvm-ppc
Cc: Michael Ellerman, Alexey Kardashevskiy, David Gibson
In-Reply-To: <20180823000858.GA17719@fergus>
On Thu, 2018-08-23 at 00:08:58 UTC, Paul Mackerras wrote:
> Commit 76fa4975f3ed ("KVM: PPC: Check if IOMMU page is contained in the
> pinned physical page", 2018-07-17) added some checks to ensure that guest
> DMA mappings don't attempt to map more than the guest is entitled to
> access. However, errors in the logic mean that legitimate guest requests
> to map pages for DMA are being denied in some situations. Specifically,
> if the first page of the range passed to mm_iommu_get() is mapped with
> a normal page, and subsequent pages are mapped with transparent huge
> pages, we end up with mem->pageshift == 0. That means that the page
> size checks in mm_iommu_ua_to_hpa() and mm_iommu_up_to_hpa_rm() will
> always fail for every page in that region, and thus the guest can never
> map any memory in that region for DMA, typically leading to a flood of
> error messages like this:
>
> qemu-system-ppc64: VFIO_MAP_DMA: -22
> qemu-system-ppc64: vfio_dma_map(0x10005f47780, 0x800000000000000, 0x10000, 0x7fff63ff0000) = -22 (Invalid argument)
>
> The logic errors in mm_iommu_get() are:
>
> (a) use of 'ua' not 'ua + (i << PAGE_SHIFT)' in the find_linux_pte() call
> (meaning that find_linux_pte() returns the pte for the first address
> in the range, not the address we are currently up to);
> (b) use of 'pageshift' as the variable to receive the hugepage shift
> returned by find_linux_pte() - for a normal page this gets set to
> 0, leading to us setting mem->pageshift to 0 when we conclude that
> the pte returned by find_linux_pte didn't match the page we were
> looking at;
> (c) comparing 'compshift', which is a page order, i.e. log base 2 of the
> number of pages, with 'pageshift', which is a log base 2 of the number
> of bytes.
>
> To fix these problems, this patch introduces 'cur_ua' to hold the current
> user address and uses that in the find_linux_pte call; introduces
> 'pteshift' to hold the hugepage shift found by find_linux_pte(); and
> compares 'pteshift' with 'compshift + PAGE_SHIFT' rather than 'compshift'.
> The patch also moves the local_irq_restore to the point after the pte
> pointer returned by find_linux_pte has been dereferenced because that
> seems safer, and adds a check to avoid doing the find_linux_pte() call
> once mem->pageshift has been reduced to PAGE_SHIFT, as an optimization.
>
> Cc: stable@vger.kernel.org # v4.12+
> Fixes: 76fa4975f3ed ("KVM: PPC: Check if IOMMU page is contained in the
> pinned physical page")
> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8cfbdbdc24815417a3ab35101ccf70
cheers
^ permalink raw reply
* Re: [1/2] powerpc/mm/books3s: Add new pte bit to mark pte temporarily invalid.
From: Michael Ellerman @ 2018-08-23 14:18 UTC (permalink / raw)
To: Aneesh Kumar K.V, npiggin, benh, paulus; +Cc: Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20180822171605.15054-1-aneesh.kumar@linux.ibm.com>
On Wed, 2018-08-22 at 17:16:04 UTC, "Aneesh Kumar K.V" wrote:
> When splitting a huge pmd pte, we need to mark the pmd entry invalid. We
> can do that by clearing _PAGE_PRESENT bit. But then that will be taken as a
> swap pte. In order to differentiate between the two use a software pte bit
> when invalidating.
>
> For regular pte, due to bd5050e38aec ("powerpc/mm/radix: Change pte relax
> sequence to handle nest MMU hang") we need to mark the pte entry invalid when
> relaxing access permission. Instead of marking pte_none which can result in
> different page table walk routines possibly skipping this pte entry, invalidate
> it but still keep it marked present.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/bd0dbb73e01306a1060e56f81e5fe2
cheers
^ permalink raw reply
* Re: powerpc/nohash: fix pte_access_permitted()
From: Michael Ellerman @ 2018-08-23 14:18 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
aneesh.kumar
Cc: linuxppc-dev, linux-kernel, stable
In-Reply-To: <8097a1d32403ea47d076803e9070869badfe24bc.1534856426.git.christophe.leroy@c-s.fr>
On Tue, 2018-08-21 at 13:03:23 UTC, Christophe Leroy wrote:
> Commit 5769beaf180a8 ("powerpc/mm: Add proper pte access check helper
> for other platforms") replaced generic pte_access_permitted() by an
> arch specific one.
>
> The generic one is defined as
> (pte_present(pte) && (!(write) || pte_write(pte)))
>
> The arch specific one is open coded checking that _PAGE_USER and
> _PAGE_WRITE (_PAGE_RW) flags are set, but lacking to check that
> _PAGE_RO and _PAGE_PRIVILEGED are unset, leading to a useless test
> on targets like the 8xx which defines _PAGE_RW and _PAGE_USER as 0.
>
> Commit 5fa5b16be5b31 ("powerpc/mm/hugetlb: Use pte_access_permitted
> for hugetlb access check") replaced some tests performed with
> pte helpers by a call to pte_access_permitted(), leading to the same
> issue.
>
> This patch rewrites powerpc/nohash pte_access_permitted()
> using pte helpers.
>
> Fixes: 5769beaf180a8 ("powerpc/mm: Add proper pte access check helper for other platforms")
> Fixes: 5fa5b16be5b31 ("powerpc/mm/hugetlb: Use pte_access_permitted for hugetlb access check")
> Cc: stable@vger.kernel.org # v4.15+
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/810e9f86f36f59f1d6f6710220c49a
cheers
^ permalink raw reply
* Re: [RESEND PATCH v2] powerpc/mce: Fix SLB rebolting during MCE recovery path.
From: Mahesh Jagannath Salgaonkar @ 2018-08-23 14:05 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: Nicholas Piggin, Aneesh Kumar K.V
In-Reply-To: <871sapl24w.fsf@concordia.ellerman.id.au>
On 08/23/2018 05:35 PM, Michael Ellerman wrote:
> Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com> writes:
>
>> On 08/23/2018 12:14 PM, Michael Ellerman wrote:
>>> Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> writes:
>>>
>>>> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>>>>
>>>> With the powerpc next commit e7e81847478 (powerpc/mce: Fix SLB rebolting
>>>> during MCE recovery path.),
>>>
>>> That commit description is wrong, I'll fix it up.
>>
>> Ouch.. My bad.. :-(
>
> To make it easier to get right, if you don't already, add these to your
> ~/.gitconfig:
>
> [pretty]
> fixes = Fixes: %h (\"%s\")
> quote = %h (\"%s\")
>
>
> And then you can do:
>
> $ git log -1 --pretty=quote e7e81847478
> e7e81847478b ("powerpc/64s: move machine check SLB flushing to mm/slb.c")
>
> $ git log -1 --pretty=fixes e7e81847478
> Fixes: e7e81847478b ("powerpc/64s: move machine check SLB flushing to mm/slb.c")
Thank you very much :-) This is going to be very handy...
-Mahesh.
^ permalink raw reply
* Re: [PATCH v2 3/4] powerpc/mm: fix a warning when a cache is common to PGD and hugepages
From: Andrew Donnellan @ 2018-08-23 13:32 UTC (permalink / raw)
To: Michael Ellerman, Russell Currey
Cc: Aneesh Kumar K.V, Benjamin Herrenschmidt, Paul Mackerras,
aneesh.kumar, linuxppc-dev, linux-kernel, Christophe LEROY,
Segher Boessenkool
In-Reply-To: <87a7pdl2jy.fsf@concordia.ellerman.id.au>
On 23/08/18 21:56, Michael Ellerman wrote:
> Christophe LEROY <christophe.leroy@c-s.fr> writes:
>=20
>> Le 23/08/2018 =C3=A0 12:36, Segher Boessenkool a =C3=A9crit=C2=A0:
>>> On Thu, Aug 23, 2018 at 11:40:22AM +0200, Christophe LEROY wrote:
>>>> The only small probl=C3=A8me I have is that some version of GCC seems =
to
>>>> complain about big memset() (132k and 256k ones). Is there a way to te=
ll
>>>> GCC we really want to do it ?
>>>
>>> I'm not sure what you mean. Complain, is that a warning, is that an er=
ror?
>>> What does it say? Do you have some example code to reproduce it? Etc.
>>
>> I saw the warnings in the checks at
>> https://patchwork.ozlabs.org/patch/957566/
>> Unfortunatly the link is now broken.
>=20
> ruscur/ajd any idea what happened to the snowpatch links here?
I think they've disappeared because our log rotation is too fast - I've=20
now upped it to 30 days. I guess over time we'll figure out what we need=20
in this regard, ideally we'd keep logs indefinitely but they're several=20
megs per build.
I've kicked off another build for this series and the links in Patchwork=20
should update to point to the new job when it's done (probably in the=20
next couple of hours).
--=20
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: DT case sensitivity
From: Grant Likely @ 2018-08-23 12:48 UTC (permalink / raw)
To: Rob Herring, Benjamin Herrenschmidt
Cc: Stephen Rothwell, Michael Ellerman, Kumar Gala, David Gibson,
Frank Rowand, devicetree-spec, devicetree, linuxppc-dev
In-Reply-To: <CAL_JsqKnbFAydf7ets0=KySm3P3b_7np-EVWz3Gh6qO+imJ+eg@mail.gmail.com>
On 23/08/2018 13:08, Rob Herring wrote:
> On Thu, Aug 23, 2018 at 6:48 AM Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>>
>> On Thu, 2018-08-23 at 06:43 -0500, Rob Herring wrote:
>>> On Thu, Aug 23, 2018 at 4:02 AM Grant Likely <grant.likely@arm.com> wro=
te:
>>>>
>>>>
>>>> What problem are you trying to solve?
>>>
>>> I'm looking at removing device_node.name and using full_name instead
>>> (which now is only the local node name plus unit-address). This means
>>> replacing of_node_cmp() (and still some strcmp) calls in a lot of
>>> places. I need to use either strncmp or strncasecmp instead.
>>>
>>>> I would think making everything
>>>> case insensitive would be the direction to go if you do anything. Leas=
t
>>>> possibility of breaking existing platforms in that scenario.
>>>
>>> Really? Even if all the "new" arches are effectively case sensitive?
>>> Anything using dtc and libfdt are (and json-schema certainly will be).
>>> But I frequently say the kernel's job is not DT validation, so you
>>> pass crap in, you get undefined results.
>>
>> I tend to agree with Grant. Let's put it this way:
>>
>> What is the drawback of being case insensitive ?
>
> It's a more expensive comparison. I don't think it's a hot path, but
> we do do a lot of string compares.
I'd hazard to argue that the cost of the string compare will not be a
source of performance problems when compared to doing a linear search
everytime a DT lookup is performed. The search algorithm is far more
problematic.
> Property names are case sensitive already. It would be nice if
> everything was treated the same way.
>
> If we're case sensitive then it is well defined which node we'll match
> and which one will be ignored. Otherwise, it is whichever one we
> happen to match first.
If case-insensitive-always is chosen, then the kernel should probably
complain at add node time if another matching node name already exists.
That's a relatively easy thing to test.
You are right however that in the FDT world we're case-sensitive now and
if it is relaxed then we're never going back. You could try switching
everyone over to case-sensitive and see if anything falls out in
linux-next for a few cycles. I would not touch the PPC or SPARC
behaviour. I don't think it is worth the risk to make the kernel more
strict when we cannot test the result. Only if everything was changed to
case-insensitive would it make sense to touch PPC and SPARC at the same
time because it reduces the number of platform variations.
If you do change compatible matches to be case sensitive, then you
should be prepared to fix bugs where the driver uses a different case
from the DTS. In which case drivers will need to be modified to accept
the deviant property names.
g.
IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
other person, use it for any purpose, or store or copy the information in =
any medium. Thank you.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox