* [PATCH v3 13/27] powerpc/powernv/pmem: Read the capability registers & wait for device ready
From: Alastair D'Silva @ 2020-02-21 3:27 UTC (permalink / raw)
To: alastair
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Masahiro Yamada,
Oliver O'Halloran, Mauro Carvalho Chehab, Ira Weiny,
Thomas Gleixner, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
Mahesh Salgaonkar, Andrew Donnellan, Arnd Bergmann, Greg Kurz,
Nicholas Piggin, Cédric Le Goater, Dan Williams,
Hari Bathini, linux-mm, Greg Kroah-Hartman, linux-kernel,
Vishal Verma, Frederic Barrat, Paul Mackerras, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <20200221032720.33893-1-alastair@au1.ibm.com>
From: Alastair D'Silva <alastair@d-silva.org>
This patch reads timeouts & firmware version from the controller, and
uses those timeouts to wait for the controller to report that it is ready
before handing the memory over to libnvdimm.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---
arch/powerpc/platforms/powernv/pmem/Makefile | 2 +-
arch/powerpc/platforms/powernv/pmem/ocxl.c | 92 +++++++++++++++++++
.../platforms/powernv/pmem/ocxl_internal.c | 19 ++++
.../platforms/powernv/pmem/ocxl_internal.h | 24 +++++
4 files changed, 136 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/platforms/powernv/pmem/ocxl_internal.c
diff --git a/arch/powerpc/platforms/powernv/pmem/Makefile b/arch/powerpc/platforms/powernv/pmem/Makefile
index 1c55c4193175..4ceda25907d4 100644
--- a/arch/powerpc/platforms/powernv/pmem/Makefile
+++ b/arch/powerpc/platforms/powernv/pmem/Makefile
@@ -4,4 +4,4 @@ ccflags-$(CONFIG_PPC_WERROR) += -Werror
obj-$(CONFIG_OCXL_PMEM) += ocxlpmem.o
-ocxlpmem-y := ocxl.o
+ocxlpmem-y := ocxl.o ocxl_internal.o
diff --git a/arch/powerpc/platforms/powernv/pmem/ocxl.c b/arch/powerpc/platforms/powernv/pmem/ocxl.c
index 3c4eeb5dcc0f..431212c9f0cc 100644
--- a/arch/powerpc/platforms/powernv/pmem/ocxl.c
+++ b/arch/powerpc/platforms/powernv/pmem/ocxl.c
@@ -8,6 +8,7 @@
#include <linux/module.h>
#include <misc/ocxl.h>
+#include <linux/delay.h>
#include <linux/ndctl.h>
#include <linux/mm_types.h>
#include <linux/memory_hotplug.h>
@@ -215,6 +216,36 @@ static int register_lpc_mem(struct ocxlpmem *ocxlpmem)
return 0;
}
+/**
+ * is_usable() - Is a controller usable?
+ * @ocxlpmem: the device metadata
+ * @verbose: True to log errors
+ * Return: true if the controller is usable
+ */
+static bool is_usable(const struct ocxlpmem *ocxlpmem, bool verbose)
+{
+ u64 chi = 0;
+ int rc = ocxlpmem_chi(ocxlpmem, &chi);
+
+ if (rc < 0)
+ return false;
+
+ if (!(chi & GLOBAL_MMIO_CHI_CRDY)) {
+ if (verbose)
+ dev_err(&ocxlpmem->dev, "controller is not ready.\n");
+ return false;
+ }
+
+ if (!(chi & GLOBAL_MMIO_CHI_MA)) {
+ if (verbose)
+ dev_err(&ocxlpmem->dev,
+ "controller does not have memory available.\n");
+ return false;
+ }
+
+ return true;
+}
+
/**
* allocate_minor() - Allocate a minor number to use for an OpenCAPI pmem device
* @ocxlpmem: the device metadata
@@ -328,6 +359,48 @@ static void ocxlpmem_remove(struct pci_dev *pdev)
}
}
+/**
+ * read_device_metadata() - Retrieve config information from the AFU and save it for future use
+ * @ocxlpmem: the device metadata
+ * Return: 0 on success, negative on failure
+ */
+static int read_device_metadata(struct ocxlpmem *ocxlpmem)
+{
+ u64 val;
+ int rc;
+
+ rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu, GLOBAL_MMIO_CCAP0,
+ OCXL_LITTLE_ENDIAN, &val);
+ if (rc)
+ return rc;
+
+ ocxlpmem->scm_revision = val & 0xFFFF;
+ ocxlpmem->read_latency = (val >> 32) & 0xFF;
+ ocxlpmem->readiness_timeout = (val >> 48) & 0x0F;
+ ocxlpmem->memory_available_timeout = val >> 52;
+
+ rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu, GLOBAL_MMIO_CCAP1,
+ OCXL_LITTLE_ENDIAN, &val);
+ if (rc)
+ return rc;
+
+ ocxlpmem->max_controller_dump_size = val & 0xFFFFFFFF;
+
+ // Extract firmware version text
+ rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu, GLOBAL_MMIO_FWVER,
+ OCXL_HOST_ENDIAN, (u64 *)ocxlpmem->fw_version);
+ if (rc)
+ return rc;
+
+ ocxlpmem->fw_version[8] = '\0';
+
+ dev_info(&ocxlpmem->dev,
+ "Firmware version '%s' SCM revision %d:%d\n", ocxlpmem->fw_version,
+ ocxlpmem->scm_revision >> 4, ocxlpmem->scm_revision & 0x0F);
+
+ return 0;
+}
+
/**
* probe_function0() - Set up function 0 for an OpenCAPI persistent memory device
* This is important as it enables templates higher than 0 across all other functions,
@@ -368,6 +441,7 @@ static int probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
struct ocxlpmem *ocxlpmem;
int rc;
+ u16 elapsed, timeout;
if (PCI_FUNC(pdev->devfn) == 0)
return probe_function0(pdev);
@@ -422,6 +496,24 @@ static int probe(struct pci_dev *pdev, const struct pci_device_id *ent)
goto err;
}
+ if (read_device_metadata(ocxlpmem)) {
+ dev_err(&pdev->dev, "Could not read metadata\n");
+ goto err;
+ }
+
+ elapsed = 0;
+ timeout = ocxlpmem->readiness_timeout + ocxlpmem->memory_available_timeout;
+ while (!is_usable(ocxlpmem, false)) {
+ if (elapsed++ > timeout) {
+ dev_warn(&ocxlpmem->dev, "OpenCAPI Persistent Memory ready timeout.\n");
+ (void)is_usable(ocxlpmem, true);
+ rc = -ENXIO;
+ goto err;
+ }
+
+ msleep(1000);
+ }
+
rc = register_lpc_mem(ocxlpmem);
if (rc) {
dev_err(&pdev->dev, "Could not register OpenCAPI persistent memory with libnvdimm\n");
diff --git a/arch/powerpc/platforms/powernv/pmem/ocxl_internal.c b/arch/powerpc/platforms/powernv/pmem/ocxl_internal.c
new file mode 100644
index 000000000000..617ca943b1b8
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/pmem/ocxl_internal.c
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2019 IBM Corp.
+
+#include <misc/ocxl.h>
+#include <linux/delay.h>
+#include "ocxl_internal.h"
+
+int ocxlpmem_chi(const struct ocxlpmem *ocxlpmem, u64 *chi)
+{
+ u64 val;
+ int rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu, GLOBAL_MMIO_CHI,
+ OCXL_LITTLE_ENDIAN, &val);
+ if (rc)
+ return rc;
+
+ *chi = val;
+
+ return 0;
+}
diff --git a/arch/powerpc/platforms/powernv/pmem/ocxl_internal.h b/arch/powerpc/platforms/powernv/pmem/ocxl_internal.h
index 9cf3e42750e7..ba0301533d00 100644
--- a/arch/powerpc/platforms/powernv/pmem/ocxl_internal.h
+++ b/arch/powerpc/platforms/powernv/pmem/ocxl_internal.h
@@ -97,4 +97,28 @@ struct ocxlpmem {
void *metadata_addr;
struct resource pmem_res;
struct nd_region *nd_region;
+ char fw_version[8+1];
+
+ u32 max_controller_dump_size;
+ u16 scm_revision; // major/minor
+ u8 readiness_timeout; /* The worst case time (in seconds) that the host shall
+ * wait for the controller to become operational following a reset (CHI.CRDY).
+ */
+ u8 memory_available_timeout; /* The worst case time (in seconds) that the host shall
+ * wait for memory to become available following a reset (CHI.MA).
+ */
+
+ u16 read_latency; /* The nominal measure of latency (in nanoseconds)
+ * associated with an unassisted read of a memory block.
+ * This represents the capability of the raw media technology without assistance
+ */
};
+
+/**
+ * ocxlpmem_chi() - Get the value of the CHI register
+ * @ocxlpmem: the device metadata
+ * @chi: returns the CHI value
+ *
+ * Returns 0 on success, negative on error
+ */
+int ocxlpmem_chi(const struct ocxlpmem *ocxlpmem, u64 *chi);
--
2.24.1
^ permalink raw reply related
* [PATCH v3 05/27] ocxl: Address kernel doc errors & warnings
From: Alastair D'Silva @ 2020-02-21 3:26 UTC (permalink / raw)
To: alastair
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Masahiro Yamada,
Oliver O'Halloran, Mauro Carvalho Chehab, Ira Weiny,
Thomas Gleixner, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
Mahesh Salgaonkar, Andrew Donnellan, Arnd Bergmann, Greg Kurz,
Nicholas Piggin, Cédric Le Goater, Dan Williams,
Hari Bathini, linux-mm, Greg Kroah-Hartman, linux-kernel,
Vishal Verma, Frederic Barrat, Paul Mackerras, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <20200221032720.33893-1-alastair@au1.ibm.com>
From: Alastair D'Silva <alastair@d-silva.org>
This patch addresses warnings and errors from the kernel doc scripts for
the OpenCAPI driver.
It also makes minor tweaks to make the docs more consistent.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---
drivers/misc/ocxl/config.c | 24 ++++----
drivers/misc/ocxl/ocxl_internal.h | 9 +--
include/misc/ocxl.h | 96 ++++++++++++-------------------
3 files changed, 55 insertions(+), 74 deletions(-)
diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c
index c8e19bfb5ef9..a62e3d7db2bf 100644
--- a/drivers/misc/ocxl/config.c
+++ b/drivers/misc/ocxl/config.c
@@ -273,16 +273,16 @@ static int read_afu_info(struct pci_dev *dev, struct ocxl_fn_config *fn,
}
/**
- * Read the template version from the AFU
- * dev: the device for the AFU
- * fn: the AFU offsets
- * len: outputs the template length
- * version: outputs the major<<8,minor version
+ * read_template_version() - Read the template version from the AFU
+ * @dev: the device for the AFU
+ * @fn: the AFU offsets
+ * @len: outputs the template length
+ * @version: outputs the major<<8,minor version
*
* Returns 0 on success, negative on failure
*/
static int read_template_version(struct pci_dev *dev, struct ocxl_fn_config *fn,
- u16 *len, u16 *version)
+ u16 *len, u16 *version)
{
u32 val32;
u8 major, minor;
@@ -476,16 +476,16 @@ static int validate_afu(struct pci_dev *dev, struct ocxl_afu_config *afu)
}
/**
- * Populate AFU metadata regarding LPC memory
- * dev: the device for the AFU
- * fn: the AFU offsets
- * afu: the AFU struct to populate the LPC metadata into
+ * read_afu_lpc_memory_info() - Populate AFU metadata regarding LPC memory
+ * @dev: the device for the AFU
+ * @fn: the AFU offsets
+ * @afu: the AFU struct to populate the LPC metadata into
*
* Returns 0 on success, negative on failure
*/
static int read_afu_lpc_memory_info(struct pci_dev *dev,
- struct ocxl_fn_config *fn,
- struct ocxl_afu_config *afu)
+ struct ocxl_fn_config *fn,
+ struct ocxl_afu_config *afu)
{
int rc;
u32 val32;
diff --git a/drivers/misc/ocxl/ocxl_internal.h b/drivers/misc/ocxl/ocxl_internal.h
index 345bf843a38e..198e4e4bc51d 100644
--- a/drivers/misc/ocxl/ocxl_internal.h
+++ b/drivers/misc/ocxl/ocxl_internal.h
@@ -122,11 +122,12 @@ int ocxl_config_check_afu_index(struct pci_dev *dev,
struct ocxl_fn_config *fn, int afu_idx);
/**
- * Update values within a Process Element
+ * ocxl_link_update_pe() - Update values within a Process Element
+ * @link_handle: the link handle associated with the process element
+ * @pasid: the PASID for the AFU context
+ * @tid: the new thread id for the process element
*
- * link_handle: the link handle associated with the process element
- * pasid: the PASID for the AFU context
- * tid: the new thread id for the process element
+ * Returns 0 on success
*/
int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid);
diff --git a/include/misc/ocxl.h b/include/misc/ocxl.h
index 0a762e387418..357ef1aadbc0 100644
--- a/include/misc/ocxl.h
+++ b/include/misc/ocxl.h
@@ -62,8 +62,7 @@ struct ocxl_context;
// Device detection & initialisation
/**
- * Open an OpenCAPI function on an OpenCAPI device
- *
+ * ocxl_function_open() - Open an OpenCAPI function on an OpenCAPI device
* @dev: The PCI device that contains the function
*
* Returns an opaque pointer to the function, or an error pointer (check with IS_ERR)
@@ -71,8 +70,7 @@ struct ocxl_context;
struct ocxl_fn *ocxl_function_open(struct pci_dev *dev);
/**
- * Get the list of AFUs associated with a PCI function device
- *
+ * ocxl_function_afu_list() - Get the list of AFUs associated with a PCI function device
* Returns a list of struct ocxl_afu *
*
* @fn: The OpenCAPI function containing the AFUs
@@ -80,8 +78,7 @@ struct ocxl_fn *ocxl_function_open(struct pci_dev *dev);
struct list_head *ocxl_function_afu_list(struct ocxl_fn *fn);
/**
- * Fetch an AFU instance from an OpenCAPI function
- *
+ * ocxl_function_fetch_afu() - Fetch an AFU instance from an OpenCAPI function
* @fn: The OpenCAPI function to get the AFU from
* @afu_idx: The index of the AFU to get
*
@@ -92,23 +89,20 @@ struct list_head *ocxl_function_afu_list(struct ocxl_fn *fn);
struct ocxl_afu *ocxl_function_fetch_afu(struct ocxl_fn *fn, u8 afu_idx);
/**
- * Take a reference to an AFU
- *
+ * ocxl_afu_get() - Take a reference to an AFU
* @afu: The AFU to increment the reference count on
*/
void ocxl_afu_get(struct ocxl_afu *afu);
/**
- * Release a reference to an AFU
- *
+ * ocxl_afu_put() - Release a reference to an AFU
* @afu: The AFU to decrement the reference count on
*/
void ocxl_afu_put(struct ocxl_afu *afu);
/**
- * Get the configuration information for an OpenCAPI function
- *
+ * ocxl_function_config() - Get the configuration information for an OpenCAPI function
* @fn: The OpenCAPI function to get the config for
*
* Returns the function config, or NULL on error
@@ -116,8 +110,7 @@ void ocxl_afu_put(struct ocxl_afu *afu);
const struct ocxl_fn_config *ocxl_function_config(struct ocxl_fn *fn);
/**
- * Close an OpenCAPI function
- *
+ * ocxl_function_close() - Close an OpenCAPI function
* This will free any AFUs previously retrieved from the function, and
* detach and associated contexts. The contexts must by freed by the caller.
*
@@ -129,8 +122,7 @@ void ocxl_function_close(struct ocxl_fn *fn);
// Context allocation
/**
- * Allocate an OpenCAPI context
- *
+ * ocxl_context_alloc() - Allocate an OpenCAPI context
* @context: The OpenCAPI context to allocate, must be freed with ocxl_context_free
* @afu: The AFU the context belongs to
* @mapping: The mapping to unmap when the context is closed (may be NULL)
@@ -139,14 +131,13 @@ int ocxl_context_alloc(struct ocxl_context **context, struct ocxl_afu *afu,
struct address_space *mapping);
/**
- * Free an OpenCAPI context
- *
+ * ocxl_context_free() - Free an OpenCAPI context
* @ctx: The OpenCAPI context to free
*/
void ocxl_context_free(struct ocxl_context *ctx);
/**
- * Grant access to an MM to an OpenCAPI context
+ * ocxl_context_attach() - Grant access to an MM to an OpenCAPI context
* @ctx: The OpenCAPI context to attach
* @amr: The value of the AMR register to restrict access
* @mm: The mm to attach to the context
@@ -157,7 +148,7 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr,
struct mm_struct *mm);
/**
- * Detach an MM from an OpenCAPI context
+ * ocxl_context_detach() - Detach an MM from an OpenCAPI context
* @ctx: The OpenCAPI context to attach
*
* Returns 0 on success, negative on failure
@@ -167,7 +158,7 @@ int ocxl_context_detach(struct ocxl_context *ctx);
// AFU IRQs
/**
- * Allocate an IRQ associated with an AFU context
+ * ocxl_afu_irq_alloc() - Allocate an IRQ associated with an AFU context
* @ctx: the AFU context
* @irq_id: out, the IRQ ID
*
@@ -176,7 +167,7 @@ int ocxl_context_detach(struct ocxl_context *ctx);
int ocxl_afu_irq_alloc(struct ocxl_context *ctx, int *irq_id);
/**
- * Frees an IRQ associated with an AFU context
+ * ocxl_afu_irq_free() - Frees an IRQ associated with an AFU context
* @ctx: the AFU context
* @irq_id: the IRQ ID
*
@@ -185,7 +176,7 @@ int ocxl_afu_irq_alloc(struct ocxl_context *ctx, int *irq_id);
int ocxl_afu_irq_free(struct ocxl_context *ctx, int irq_id);
/**
- * Gets the address of the trigger page for an IRQ
+ * ocxl_afu_irq_get_addr() - Gets the address of the trigger page for an IRQ
* This can then be provided to an AFU which will write to that
* page to trigger the IRQ.
* @ctx: The AFU context that the IRQ is associated with
@@ -196,7 +187,7 @@ int ocxl_afu_irq_free(struct ocxl_context *ctx, int irq_id);
u64 ocxl_afu_irq_get_addr(struct ocxl_context *ctx, int irq_id);
/**
- * Provide a callback to be called when an IRQ is triggered
+ * ocxl_irq_set_handler() - Provide a callback to be called when an IRQ is triggered
* @ctx: The AFU context that the IRQ is associated with
* @irq_id: The IRQ ID
* @handler: the callback to be called when the IRQ is triggered
@@ -213,8 +204,7 @@ int ocxl_irq_set_handler(struct ocxl_context *ctx, int irq_id,
// AFU Metadata
/**
- * Get a pointer to the config for an AFU
- *
+ * ocxl_afu_config() - Get a pointer to the config for an AFU
* @afu: a pointer to the AFU to get the config for
*
* Returns a pointer to the AFU config
@@ -222,27 +212,24 @@ int ocxl_irq_set_handler(struct ocxl_context *ctx, int irq_id,
struct ocxl_afu_config *ocxl_afu_config(struct ocxl_afu *afu);
/**
- * Assign opaque hardware specific information to an OpenCAPI AFU.
- *
- * @dev: The PCI device associated with the OpenCAPI device
+ * ocxl_afu_set_private() - Assign opaque hardware specific information to an OpenCAPI AFU.
+ * @afu: The OpenCAPI AFU
* @private: the opaque hardware specific information to assign to the driver
*/
void ocxl_afu_set_private(struct ocxl_afu *afu, void *private);
/**
- * Fetch the hardware specific information associated with an external OpenCAPI
- * AFU. This may be consumed by an external OpenCAPI driver.
- *
- * @afu: The AFU
+ * ocxl_afu_get_private() - Fetch the hardware specific information associated with
+ * an external OpenCAPI AFU. This may be consumed by an external OpenCAPI driver.
+ * @afu: The OpenCAPI AFU
*
* Returns the opaque pointer associated with the device, or NULL if not set
*/
-void *ocxl_afu_get_private(struct ocxl_afu *dev);
+void *ocxl_afu_get_private(struct ocxl_afu *afu);
// Global MMIO
/**
- * Read a 32 bit value from global MMIO
- *
+ * ocxl_global_mmio_read32() - Read a 32 bit value from global MMIO
* @afu: The AFU
* @offset: The Offset from the start of MMIO
* @endian: the endianness that the MMIO data is in
@@ -251,11 +238,10 @@ void *ocxl_afu_get_private(struct ocxl_afu *dev);
* Returns 0 for success, negative on error
*/
int ocxl_global_mmio_read32(struct ocxl_afu *afu, size_t offset,
- enum ocxl_endian endian, u32 *val);
+ enum ocxl_endian endian, u32 *val);
/**
- * Read a 64 bit value from global MMIO
- *
+ * ocxl_global_mmio_read64() - Read a 64 bit value from global MMIO
* @afu: The AFU
* @offset: The Offset from the start of MMIO
* @endian: the endianness that the MMIO data is in
@@ -264,11 +250,10 @@ int ocxl_global_mmio_read32(struct ocxl_afu *afu, size_t offset,
* Returns 0 for success, negative on error
*/
int ocxl_global_mmio_read64(struct ocxl_afu *afu, size_t offset,
- enum ocxl_endian endian, u64 *val);
+ enum ocxl_endian endian, u64 *val);
/**
- * Write a 32 bit value to global MMIO
- *
+ * ocxl_global_mmio_write32() - Write a 32 bit value to global MMIO
* @afu: The AFU
* @offset: The Offset from the start of MMIO
* @endian: the endianness that the MMIO data is in
@@ -277,11 +262,10 @@ int ocxl_global_mmio_read64(struct ocxl_afu *afu, size_t offset,
* Returns 0 for success, negative on error
*/
int ocxl_global_mmio_write32(struct ocxl_afu *afu, size_t offset,
- enum ocxl_endian endian, u32 val);
+ enum ocxl_endian endian, u32 val);
/**
- * Write a 64 bit value to global MMIO
- *
+ * ocxl_global_mmio_write64() - Write a 64 bit value to global MMIO
* @afu: The AFU
* @offset: The Offset from the start of MMIO
* @endian: the endianness that the MMIO data is in
@@ -290,11 +274,10 @@ int ocxl_global_mmio_write32(struct ocxl_afu *afu, size_t offset,
* Returns 0 for success, negative on error
*/
int ocxl_global_mmio_write64(struct ocxl_afu *afu, size_t offset,
- enum ocxl_endian endian, u64 val);
+ enum ocxl_endian endian, u64 val);
/**
- * Set bits in a 32 bit global MMIO register
- *
+ * ocxl_global_mmio_set32() - Set bits in a 32 bit global MMIO register
* @afu: The AFU
* @offset: The Offset from the start of MMIO
* @endian: the endianness that the MMIO data is in
@@ -303,11 +286,10 @@ int ocxl_global_mmio_write64(struct ocxl_afu *afu, size_t offset,
* Returns 0 for success, negative on error
*/
int ocxl_global_mmio_set32(struct ocxl_afu *afu, size_t offset,
- enum ocxl_endian endian, u32 mask);
+ enum ocxl_endian endian, u32 mask);
/**
- * Set bits in a 64 bit global MMIO register
- *
+ * ocxl_global_mmio_set64() - Set bits in a 64 bit global MMIO register
* @afu: The AFU
* @offset: The Offset from the start of MMIO
* @endian: the endianness that the MMIO data is in
@@ -316,11 +298,10 @@ int ocxl_global_mmio_set32(struct ocxl_afu *afu, size_t offset,
* Returns 0 for success, negative on error
*/
int ocxl_global_mmio_set64(struct ocxl_afu *afu, size_t offset,
- enum ocxl_endian endian, u64 mask);
+ enum ocxl_endian endian, u64 mask);
/**
- * Set bits in a 32 bit global MMIO register
- *
+ * ocxl_global_mmio_clear32() - Set bits in a 32 bit global MMIO register
* @afu: The AFU
* @offset: The Offset from the start of MMIO
* @endian: the endianness that the MMIO data is in
@@ -329,11 +310,10 @@ int ocxl_global_mmio_set64(struct ocxl_afu *afu, size_t offset,
* Returns 0 for success, negative on error
*/
int ocxl_global_mmio_clear32(struct ocxl_afu *afu, size_t offset,
- enum ocxl_endian endian, u32 mask);
+ enum ocxl_endian endian, u32 mask);
/**
- * Set bits in a 64 bit global MMIO register
- *
+ * ocxl_global_mmio_clear64() - Set bits in a 64 bit global MMIO register
* @afu: The AFU
* @offset: The Offset from the start of MMIO
* @endian: the endianness that the MMIO data is in
@@ -342,7 +322,7 @@ int ocxl_global_mmio_clear32(struct ocxl_afu *afu, size_t offset,
* Returns 0 for success, negative on error
*/
int ocxl_global_mmio_clear64(struct ocxl_afu *afu, size_t offset,
- enum ocxl_endian endian, u64 mask);
+ enum ocxl_endian endian, u64 mask);
// Functions left here are for compatibility with the cxlflash driver
--
2.24.1
^ permalink raw reply related
* [PATCH v3 26/27] powerpc/powernv/pmem: Expose the firmware version in sysfs
From: Alastair D'Silva @ 2020-02-21 3:27 UTC (permalink / raw)
To: alastair
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Masahiro Yamada,
Oliver O'Halloran, Mauro Carvalho Chehab, Ira Weiny,
Thomas Gleixner, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
Mahesh Salgaonkar, Andrew Donnellan, Arnd Bergmann, Greg Kurz,
Nicholas Piggin, Cédric Le Goater, Dan Williams,
Hari Bathini, linux-mm, Greg Kroah-Hartman, linux-kernel,
Vishal Verma, Frederic Barrat, Paul Mackerras, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <20200221032720.33893-1-alastair@au1.ibm.com>
From: Alastair D'Silva <alastair@d-silva.org>
This information will be used by ndctl in userspace to help users identify
the device.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---
arch/powerpc/platforms/powernv/pmem/ocxl_sysfs.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/pmem/ocxl_sysfs.c b/arch/powerpc/platforms/powernv/pmem/ocxl_sysfs.c
index 7829e4bc887d..84b23cc3e8b7 100644
--- a/arch/powerpc/platforms/powernv/pmem/ocxl_sysfs.c
+++ b/arch/powerpc/platforms/powernv/pmem/ocxl_sysfs.c
@@ -16,8 +16,17 @@ static ssize_t serial_show(struct device *device, struct device_attribute *attr,
return scnprintf(buf, PAGE_SIZE, "%llu\n", fn_config->serial);
}
+static ssize_t fw_version_show(struct device *device,
+ struct device_attribute *attr, char *buf)
+{
+ struct ocxlpmem *ocxlpmem = container_of(device, struct ocxlpmem, dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%s\n", ocxlpmem->fw_version);
+}
+
static struct device_attribute attrs[] = {
__ATTR_RO(serial),
+ __ATTR_RO(fw_version),
};
int ocxlpmem_sysfs_add(struct ocxlpmem *ocxlpmem)
--
2.24.1
^ permalink raw reply related
* [PATCH v3 07/27] ocxl: Add functions to map/unmap LPC memory
From: Alastair D'Silva @ 2020-02-21 3:27 UTC (permalink / raw)
To: alastair
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Masahiro Yamada,
Oliver O'Halloran, Mauro Carvalho Chehab, Ira Weiny,
Thomas Gleixner, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
Mahesh Salgaonkar, Andrew Donnellan, Arnd Bergmann, Greg Kurz,
Nicholas Piggin, Cédric Le Goater, Dan Williams,
Hari Bathini, linux-mm, Greg Kroah-Hartman, linux-kernel,
Vishal Verma, Frederic Barrat, Paul Mackerras, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <20200221032720.33893-1-alastair@au1.ibm.com>
From: Alastair D'Silva <alastair@d-silva.org>
Add functions to map/unmap LPC memory
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---
drivers/misc/ocxl/core.c | 51 +++++++++++++++++++++++++++++++
drivers/misc/ocxl/ocxl_internal.h | 3 ++
include/misc/ocxl.h | 21 +++++++++++++
3 files changed, 75 insertions(+)
diff --git a/drivers/misc/ocxl/core.c b/drivers/misc/ocxl/core.c
index 2531c6cf19a0..75ff14e3882a 100644
--- a/drivers/misc/ocxl/core.c
+++ b/drivers/misc/ocxl/core.c
@@ -210,6 +210,56 @@ static void unmap_mmio_areas(struct ocxl_afu *afu)
release_fn_bar(afu->fn, afu->config.global_mmio_bar);
}
+int ocxl_afu_map_lpc_mem(struct ocxl_afu *afu)
+{
+ struct pci_dev *dev = to_pci_dev(afu->fn->dev.parent);
+
+ if ((afu->config.lpc_mem_size + afu->config.special_purpose_mem_size) == 0)
+ return 0;
+
+ afu->lpc_base_addr = ocxl_link_lpc_map(afu->fn->link, dev);
+ if (afu->lpc_base_addr == 0)
+ return -EINVAL;
+
+ if (afu->config.lpc_mem_size > 0) {
+ afu->lpc_res.start = afu->lpc_base_addr + afu->config.lpc_mem_offset;
+ afu->lpc_res.end = afu->lpc_res.start + afu->config.lpc_mem_size - 1;
+ }
+
+ if (afu->config.special_purpose_mem_size > 0) {
+ afu->special_purpose_res.start = afu->lpc_base_addr +
+ afu->config.special_purpose_mem_offset;
+ afu->special_purpose_res.end = afu->special_purpose_res.start +
+ afu->config.special_purpose_mem_size - 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ocxl_afu_map_lpc_mem);
+
+struct resource *ocxl_afu_lpc_mem(struct ocxl_afu *afu)
+{
+ return &afu->lpc_res;
+}
+EXPORT_SYMBOL_GPL(ocxl_afu_lpc_mem);
+
+static void unmap_lpc_mem(struct ocxl_afu *afu)
+{
+ struct pci_dev *dev = to_pci_dev(afu->fn->dev.parent);
+
+ if (afu->lpc_res.start || afu->special_purpose_res.start) {
+ void *link = afu->fn->link;
+
+ // only release the link when the the last consumer calls release
+ ocxl_link_lpc_release(link, dev);
+
+ afu->lpc_res.start = 0;
+ afu->lpc_res.end = 0;
+ afu->special_purpose_res.start = 0;
+ afu->special_purpose_res.end = 0;
+ }
+}
+
static int configure_afu(struct ocxl_afu *afu, u8 afu_idx, struct pci_dev *dev)
{
int rc;
@@ -251,6 +301,7 @@ static int configure_afu(struct ocxl_afu *afu, u8 afu_idx, struct pci_dev *dev)
static void deconfigure_afu(struct ocxl_afu *afu)
{
+ unmap_lpc_mem(afu);
unmap_mmio_areas(afu);
reclaim_afu_pasid(afu);
reclaim_afu_actag(afu);
diff --git a/drivers/misc/ocxl/ocxl_internal.h b/drivers/misc/ocxl/ocxl_internal.h
index d0c8c4838f42..ce0cac1da416 100644
--- a/drivers/misc/ocxl/ocxl_internal.h
+++ b/drivers/misc/ocxl/ocxl_internal.h
@@ -52,6 +52,9 @@ struct ocxl_afu {
void __iomem *global_mmio_ptr;
u64 pp_mmio_start;
void *private;
+ u64 lpc_base_addr; /* Covers both LPC & special purpose memory */
+ struct resource lpc_res;
+ struct resource special_purpose_res;
};
enum ocxl_context_status {
diff --git a/include/misc/ocxl.h b/include/misc/ocxl.h
index 357ef1aadbc0..d8b0b4d46bfb 100644
--- a/include/misc/ocxl.h
+++ b/include/misc/ocxl.h
@@ -203,6 +203,27 @@ int ocxl_irq_set_handler(struct ocxl_context *ctx, int irq_id,
// AFU Metadata
+/**
+ * ocxl_afu_map_lpc_mem() - Map the LPC system & special purpose memory for an AFU
+ * Do not call this during device discovery, as there may me multiple
+ * devices on a link, and the memory is mapped for the whole link, not
+ * just one device. It should only be called after all devices have
+ * registered their memory on the link.
+ *
+ * @afu: The AFU that has the LPC memory to map
+ *
+ * Returns 0 on success, negative on failure
+ */
+int ocxl_afu_map_lpc_mem(struct ocxl_afu *afu);
+
+/**
+ * ocxl_afu_lpc_mem() - Get the physical address range of LPC memory for an AFU
+ * @afu: The AFU associated with the LPC memory
+ *
+ * Returns a pointer to the resource struct for the physical address range
+ */
+struct resource *ocxl_afu_lpc_mem(struct ocxl_afu *afu);
+
/**
* ocxl_afu_config() - Get a pointer to the config for an AFU
* @afu: a pointer to the AFU to get the config for
--
2.24.1
^ permalink raw reply related
* [PATCH v3 09/27] ocxl: Save the device serial number in ocxl_fn
From: Alastair D'Silva @ 2020-02-21 3:27 UTC (permalink / raw)
To: alastair
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Masahiro Yamada,
Oliver O'Halloran, Mauro Carvalho Chehab, Ira Weiny,
Thomas Gleixner, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
Mahesh Salgaonkar, Andrew Donnellan, Arnd Bergmann, Greg Kurz,
Nicholas Piggin, Cédric Le Goater, Dan Williams,
Hari Bathini, linux-mm, Greg Kroah-Hartman, linux-kernel,
Vishal Verma, Frederic Barrat, Paul Mackerras, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <20200221032720.33893-1-alastair@au1.ibm.com>
From: Alastair D'Silva <alastair@d-silva.org>
This patch retrieves the serial number of the card and makes it available
to consumers of the ocxl driver via the ocxl_fn struct.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
---
drivers/misc/ocxl/config.c | 46 ++++++++++++++++++++++++++++++++++++++
include/misc/ocxl.h | 1 +
2 files changed, 47 insertions(+)
diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c
index 701ae6216abf..ce33fafa7b50 100644
--- a/drivers/misc/ocxl/config.c
+++ b/drivers/misc/ocxl/config.c
@@ -71,6 +71,51 @@ static int find_dvsec_afu_ctrl(struct pci_dev *dev, u8 afu_idx)
return 0;
}
+/**
+ * get_function_0() - Find a related PCI device (function 0)
+ * @device: PCI device to match
+ *
+ * Returns a pointer to the related device, or null if not found
+ */
+static struct pci_dev *get_function_0(struct pci_dev *dev)
+{
+ unsigned int devfn = PCI_DEVFN(PCI_SLOT(dev->devfn), 0);
+
+ return pci_get_domain_bus_and_slot(pci_domain_nr(dev->bus),
+ dev->bus->number, devfn);
+}
+
+static void read_serial(struct pci_dev *dev, struct ocxl_fn_config *fn)
+{
+ u32 low, high;
+ int pos;
+
+ pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DSN);
+ if (pos) {
+ pci_read_config_dword(dev, pos + 0x04, &low);
+ pci_read_config_dword(dev, pos + 0x08, &high);
+
+ fn->serial = low | ((u64)high) << 32;
+
+ return;
+ }
+
+ if (PCI_FUNC(dev->devfn) != 0) {
+ struct pci_dev *related = get_function_0(dev);
+
+ if (!related) {
+ fn->serial = 0;
+ return;
+ }
+
+ read_serial(related, fn);
+ pci_dev_put(related);
+ return;
+ }
+
+ fn->serial = 0;
+}
+
static void read_pasid(struct pci_dev *dev, struct ocxl_fn_config *fn)
{
u16 val;
@@ -208,6 +253,7 @@ int ocxl_config_read_function(struct pci_dev *dev, struct ocxl_fn_config *fn)
int rc;
read_pasid(dev, fn);
+ read_serial(dev, fn);
rc = read_dvsec_tl(dev, fn);
if (rc) {
diff --git a/include/misc/ocxl.h b/include/misc/ocxl.h
index d8b0b4d46bfb..b8514dc64bd0 100644
--- a/include/misc/ocxl.h
+++ b/include/misc/ocxl.h
@@ -46,6 +46,7 @@ struct ocxl_fn_config {
int dvsec_afu_info_pos; /* offset of the AFU information DVSEC */
s8 max_pasid_log;
s8 max_afu_index;
+ u64 serial;
};
enum ocxl_endian {
--
2.24.1
^ permalink raw reply related
* [PATCH v3 06/27] ocxl: Tally up the LPC memory on a link & allow it to be mapped
From: Alastair D'Silva @ 2020-02-21 3:26 UTC (permalink / raw)
To: alastair
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Masahiro Yamada,
Oliver O'Halloran, Mauro Carvalho Chehab, Ira Weiny,
Thomas Gleixner, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
Mahesh Salgaonkar, Andrew Donnellan, Arnd Bergmann, Greg Kurz,
Nicholas Piggin, Cédric Le Goater, Dan Williams,
Hari Bathini, linux-mm, Greg Kroah-Hartman, linux-kernel,
Vishal Verma, Frederic Barrat, Paul Mackerras, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <20200221032720.33893-1-alastair@au1.ibm.com>
From: Alastair D'Silva <alastair@d-silva.org>
Tally up the LPC memory on an OpenCAPI link & allow it to be mapped
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---
drivers/misc/ocxl/core.c | 10 ++++++
drivers/misc/ocxl/link.c | 53 +++++++++++++++++++++++++++++++
drivers/misc/ocxl/ocxl_internal.h | 33 +++++++++++++++++++
3 files changed, 96 insertions(+)
diff --git a/drivers/misc/ocxl/core.c b/drivers/misc/ocxl/core.c
index b7a09b21ab36..2531c6cf19a0 100644
--- a/drivers/misc/ocxl/core.c
+++ b/drivers/misc/ocxl/core.c
@@ -230,8 +230,18 @@ static int configure_afu(struct ocxl_afu *afu, u8 afu_idx, struct pci_dev *dev)
if (rc)
goto err_free_pasid;
+ if (afu->config.lpc_mem_size || afu->config.special_purpose_mem_size) {
+ rc = ocxl_link_add_lpc_mem(afu->fn->link, afu->config.lpc_mem_offset,
+ afu->config.lpc_mem_size +
+ afu->config.special_purpose_mem_size);
+ if (rc)
+ goto err_free_mmio;
+ }
+
return 0;
+err_free_mmio:
+ unmap_mmio_areas(afu);
err_free_pasid:
reclaim_afu_pasid(afu);
err_free_actag:
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index 58d111afd9f6..1e039cc5ebe5 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -84,6 +84,11 @@ struct ocxl_link {
int dev;
atomic_t irq_available;
struct spa *spa;
+ struct mutex lpc_mem_lock; /* protects lpc_mem & lpc_mem_sz */
+ u64 lpc_mem_sz; /* Total amount of LPC memory presented on the link */
+ u64 lpc_mem;
+ int lpc_consumers;
+
void *platform_data;
};
static struct list_head links_list = LIST_HEAD_INIT(links_list);
@@ -396,6 +401,8 @@ static int alloc_link(struct pci_dev *dev, int PE_mask, struct ocxl_link **out_l
if (rc)
goto err_spa;
+ mutex_init(&link->lpc_mem_lock);
+
/* platform specific hook */
rc = pnv_ocxl_spa_setup(dev, link->spa->spa_mem, PE_mask,
&link->platform_data);
@@ -711,3 +718,49 @@ void ocxl_link_free_irq(void *link_handle, int hw_irq)
atomic_inc(&link->irq_available);
}
EXPORT_SYMBOL_GPL(ocxl_link_free_irq);
+
+int ocxl_link_add_lpc_mem(void *link_handle, u64 offset, u64 size)
+{
+ struct ocxl_link *link = (struct ocxl_link *) link_handle;
+
+ // Check for overflow
+ if (offset > (offset + size))
+ return -EINVAL;
+
+ mutex_lock(&link->lpc_mem_lock);
+ link->lpc_mem_sz = max(link->lpc_mem_sz, offset + size);
+
+ mutex_unlock(&link->lpc_mem_lock);
+
+ return 0;
+}
+
+u64 ocxl_link_lpc_map(void *link_handle, struct pci_dev *pdev)
+{
+ struct ocxl_link *link = (struct ocxl_link *) link_handle;
+
+ mutex_lock(&link->lpc_mem_lock);
+
+ if(!link->lpc_mem)
+ link->lpc_mem = pnv_ocxl_platform_lpc_setup(pdev, link->lpc_mem_sz);
+
+ if(link->lpc_mem)
+ link->lpc_consumers++;
+ mutex_unlock(&link->lpc_mem_lock);
+
+ return link->lpc_mem;
+}
+
+void ocxl_link_lpc_release(void *link_handle, struct pci_dev *pdev)
+{
+ struct ocxl_link *link = (struct ocxl_link *) link_handle;
+
+ mutex_lock(&link->lpc_mem_lock);
+ WARN_ON(--link->lpc_consumers < 0);
+ if (link->lpc_consumers == 0) {
+ pnv_ocxl_platform_lpc_release(pdev);
+ link->lpc_mem = 0;
+ }
+
+ mutex_unlock(&link->lpc_mem_lock);
+}
diff --git a/drivers/misc/ocxl/ocxl_internal.h b/drivers/misc/ocxl/ocxl_internal.h
index 198e4e4bc51d..d0c8c4838f42 100644
--- a/drivers/misc/ocxl/ocxl_internal.h
+++ b/drivers/misc/ocxl/ocxl_internal.h
@@ -142,4 +142,37 @@ int ocxl_irq_offset_to_id(struct ocxl_context *ctx, u64 offset);
u64 ocxl_irq_id_to_offset(struct ocxl_context *ctx, int irq_id);
void ocxl_afu_irq_free_all(struct ocxl_context *ctx);
+/**
+ * ocxl_link_add_lpc_mem() - Increment the amount of memory required by an OpenCAPI link
+ *
+ * @link_handle: The OpenCAPI link handle
+ * @offset: The offset of the memory to add
+ * @size: The amount of memory to increment by
+ *
+ * Returns 0 on success, negative on overflow
+ */
+int ocxl_link_add_lpc_mem(void *link_handle, u64 offset, u64 size);
+
+/**
+ * ocxl_link_lpc_map() - Map the LPC memory for an OpenCAPI device
+ * Since LPC memory belongs to a link, the whole LPC memory available
+ * on the link must be mapped in order to make it accessible to a device.
+ * @link_handle: The OpenCAPI link handle
+ * @pdev: A device that is on the link
+ *
+ * Returns the address of the mapped LPC memory, or 0 on error
+ */
+u64 ocxl_link_lpc_map(void *link_handle, struct pci_dev *pdev);
+
+/**
+ * ocxl_link_lpc_release() - Release the LPC memory device for an OpenCAPI device
+ *
+ * Offlines LPC memory on an OpenCAPI link for a device. If this is the
+ * last device on the link to release the memory, unmap it from the link.
+ *
+ * @link_handle: The OpenCAPI link handle
+ * @pdev: A device that is on the link
+ */
+void ocxl_link_lpc_release(void *link_handle, struct pci_dev *pdev);
+
#endif /* _OCXL_INTERNAL_H_ */
--
2.24.1
^ permalink raw reply related
* [PATCH v3 00/27] Add support for OpenCAPI Persistent Memory devices
From: Alastair D'Silva @ 2020-02-21 3:26 UTC (permalink / raw)
To: alastair
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Masahiro Yamada,
Oliver O'Halloran, Mauro Carvalho Chehab, Ira Weiny,
Thomas Gleixner, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
Mahesh Salgaonkar, Andrew Donnellan, Arnd Bergmann, Greg Kurz,
Nicholas Piggin, Cédric Le Goater, Dan Williams,
Hari Bathini, linux-mm, Greg Kroah-Hartman, linux-kernel,
Vishal Verma, Frederic Barrat, Paul Mackerras, Andrew Morton,
linuxppc-dev, David S. Miller
From: Alastair D'Silva <alastair@d-silva.org>
This series adds support for OpenCAPI Persistent Memory devices, exposing
them as nvdimms so that we can make use of the existing infrastructure.
Alastair D'Silva (27):
powerpc: Add OPAL calls for LPC memory alloc/release
mm/memory_hotplug: Allow check_hotplug_memory_addressable to be called
from drivers
powerpc: Map & release OpenCAPI LPC memory
ocxl: Remove unnecessary externs
ocxl: Address kernel doc errors & warnings
ocxl: Tally up the LPC memory on a link & allow it to be mapped
ocxl: Add functions to map/unmap LPC memory
ocxl: Emit a log message showing how much LPC memory was detected
ocxl: Save the device serial number in ocxl_fn
powerpc: Add driver for OpenCAPI Persistent Memory
powerpc: Enable the OpenCAPI Persistent Memory driver for
powernv_defconfig
powerpc/powernv/pmem: Add register addresses & status values to the
header
powerpc/powernv/pmem: Read the capability registers & wait for device
ready
powerpc/powernv/pmem: Add support for Admin commands
powerpc/powernv/pmem: Add support for near storage commands
powerpc/powernv/pmem: Register a character device for userspace to
interact with
powerpc/powernv/pmem: Implement the Read Error Log command
powerpc/powernv/pmem: Add controller dump IOCTLs
powerpc/powernv/pmem: Add an IOCTL to report controller statistics
powerpc/powernv/pmem: Forward events to userspace
powerpc/powernv/pmem: Add an IOCTL to request controller health & perf
data
powerpc/powernv/pmem: Implement the heartbeat command
powerpc/powernv/pmem: Add debug IOCTLs
powerpc/powernv/pmem: Expose SMART data via ndctl
powerpc/powernv/pmem: Expose the serial number in sysfs
powerpc/powernv/pmem: Expose the firmware version in sysfs
MAINTAINERS: Add myself & nvdimm/ocxl to ocxl
MAINTAINERS | 3 +
arch/powerpc/configs/powernv_defconfig | 5 +
arch/powerpc/include/asm/opal-api.h | 2 +
arch/powerpc/include/asm/opal.h | 3 +
arch/powerpc/include/asm/pnv-ocxl.h | 40 +-
arch/powerpc/platforms/powernv/Kconfig | 3 +
arch/powerpc/platforms/powernv/Makefile | 1 +
arch/powerpc/platforms/powernv/ocxl.c | 43 +
arch/powerpc/platforms/powernv/opal-call.c | 2 +
arch/powerpc/platforms/powernv/pmem/Kconfig | 21 +
arch/powerpc/platforms/powernv/pmem/Makefile | 7 +
arch/powerpc/platforms/powernv/pmem/ocxl.c | 1991 +++++++++++++++++
.../platforms/powernv/pmem/ocxl_internal.c | 213 ++
.../platforms/powernv/pmem/ocxl_internal.h | 254 +++
.../platforms/powernv/pmem/ocxl_sysfs.c | 46 +
drivers/misc/ocxl/config.c | 74 +-
drivers/misc/ocxl/core.c | 61 +
drivers/misc/ocxl/link.c | 53 +
drivers/misc/ocxl/ocxl_internal.h | 45 +-
include/linux/memory_hotplug.h | 5 +
include/misc/ocxl.h | 122 +-
include/uapi/linux/ndctl.h | 1 +
include/uapi/nvdimm/ocxl-pmem.h | 127 ++
mm/memory_hotplug.c | 4 +-
24 files changed, 3029 insertions(+), 97 deletions(-)
create mode 100644 arch/powerpc/platforms/powernv/pmem/Kconfig
create mode 100644 arch/powerpc/platforms/powernv/pmem/Makefile
create mode 100644 arch/powerpc/platforms/powernv/pmem/ocxl.c
create mode 100644 arch/powerpc/platforms/powernv/pmem/ocxl_internal.c
create mode 100644 arch/powerpc/platforms/powernv/pmem/ocxl_internal.h
create mode 100644 arch/powerpc/platforms/powernv/pmem/ocxl_sysfs.c
create mode 100644 include/uapi/nvdimm/ocxl-pmem.h
--
2.24.1
^ permalink raw reply
* [PATCH v3 01/27] powerpc: Add OPAL calls for LPC memory alloc/release
From: Alastair D'Silva @ 2020-02-21 3:26 UTC (permalink / raw)
To: alastair
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Masahiro Yamada,
Oliver O'Halloran, Mauro Carvalho Chehab, Ira Weiny,
Thomas Gleixner, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
Mahesh Salgaonkar, Andrew Donnellan, Arnd Bergmann, Greg Kurz,
Nicholas Piggin, Cédric Le Goater, Dan Williams,
Hari Bathini, linux-mm, Greg Kroah-Hartman, linux-kernel,
Vishal Verma, Frederic Barrat, Paul Mackerras, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <20200221032720.33893-1-alastair@au1.ibm.com>
From: Alastair D'Silva <alastair@d-silva.org>
Add OPAL calls for LPC memory alloc/release
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
---
arch/powerpc/include/asm/opal-api.h | 2 ++
arch/powerpc/include/asm/opal.h | 3 +++
arch/powerpc/platforms/powernv/opal-call.c | 2 ++
3 files changed, 7 insertions(+)
diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
index c1f25a760eb1..9298e603001b 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -208,6 +208,8 @@
#define OPAL_HANDLE_HMI2 166
#define OPAL_NX_COPROC_INIT 167
#define OPAL_XIVE_GET_VP_STATE 170
+#define OPAL_NPU_MEM_ALLOC 171
+#define OPAL_NPU_MEM_RELEASE 172
#define OPAL_MPIPL_UPDATE 173
#define OPAL_MPIPL_REGISTER_TAG 174
#define OPAL_MPIPL_QUERY_TAG 175
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9986ac34b8e2..8f7727e0f9ce 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -39,6 +39,9 @@ int64_t opal_npu_spa_clear_cache(uint64_t phb_id, uint32_t bdfn,
uint64_t PE_handle);
int64_t opal_npu_tl_set(uint64_t phb_id, uint32_t bdfn, long cap,
uint64_t rate_phys, uint32_t size);
+int64_t opal_npu_mem_alloc(uint64_t phb_id, uint32_t bdfn,
+ uint64_t size, uint64_t *bar);
+int64_t opal_npu_mem_release(uint64_t phb_id, uint32_t bdfn);
int64_t opal_console_write(int64_t term_number, __be64 *length,
const uint8_t *buffer);
diff --git a/arch/powerpc/platforms/powernv/opal-call.c b/arch/powerpc/platforms/powernv/opal-call.c
index 5cd0f52d258f..f26e58b72c04 100644
--- a/arch/powerpc/platforms/powernv/opal-call.c
+++ b/arch/powerpc/platforms/powernv/opal-call.c
@@ -287,6 +287,8 @@ OPAL_CALL(opal_pci_set_pbcq_tunnel_bar, OPAL_PCI_SET_PBCQ_TUNNEL_BAR);
OPAL_CALL(opal_sensor_read_u64, OPAL_SENSOR_READ_U64);
OPAL_CALL(opal_sensor_group_enable, OPAL_SENSOR_GROUP_ENABLE);
OPAL_CALL(opal_nx_coproc_init, OPAL_NX_COPROC_INIT);
+OPAL_CALL(opal_npu_mem_alloc, OPAL_NPU_MEM_ALLOC);
+OPAL_CALL(opal_npu_mem_release, OPAL_NPU_MEM_RELEASE);
OPAL_CALL(opal_mpipl_update, OPAL_MPIPL_UPDATE);
OPAL_CALL(opal_mpipl_register_tag, OPAL_MPIPL_REGISTER_TAG);
OPAL_CALL(opal_mpipl_query_tag, OPAL_MPIPL_QUERY_TAG);
--
2.24.1
^ permalink raw reply related
* [PATCH v3 02/27] mm/memory_hotplug: Allow check_hotplug_memory_addressable to be called from drivers
From: Alastair D'Silva @ 2020-02-21 3:26 UTC (permalink / raw)
To: alastair
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Masahiro Yamada,
Oliver O'Halloran, Mauro Carvalho Chehab, Ira Weiny,
Thomas Gleixner, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
Mahesh Salgaonkar, Andrew Donnellan, Arnd Bergmann, Greg Kurz,
Nicholas Piggin, Cédric Le Goater, Dan Williams,
Hari Bathini, linux-mm, Greg Kroah-Hartman, linux-kernel,
Vishal Verma, Frederic Barrat, Paul Mackerras, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <20200221032720.33893-1-alastair@au1.ibm.com>
From: Alastair D'Silva <alastair@d-silva.org>
When setting up OpenCAPI connected persistent memory, the range check may
not be performed until quite late (or perhaps not at all, if the user does
not establish a DAX device).
This patch makes the range check callable so we can perform the check while
probing the OpenCAPI SCM device.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---
include/linux/memory_hotplug.h | 5 +++++
mm/memory_hotplug.c | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index f4d59155f3d4..34a69aecc45e 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -337,6 +337,11 @@ static inline void __remove_memory(int nid, u64 start, u64 size) {}
extern void set_zone_contiguous(struct zone *zone);
extern void clear_zone_contiguous(struct zone *zone);
+#ifdef CONFIG_MEMORY_HOTPLUG_SPARSE
+int check_hotplug_memory_addressable(unsigned long pfn,
+ unsigned long nr_pages);
+#endif /* CONFIG_MEMORY_HOTPLUG_SPARSE */
+
extern void __ref free_area_init_core_hotplug(int nid);
extern int __add_memory(int nid, u64 start, u64 size);
extern int add_memory(int nid, u64 start, u64 size);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 0a54ffac8c68..14945f033594 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -276,8 +276,8 @@ static int check_pfn_span(unsigned long pfn, unsigned long nr_pages,
return 0;
}
-static int check_hotplug_memory_addressable(unsigned long pfn,
- unsigned long nr_pages)
+int check_hotplug_memory_addressable(unsigned long pfn,
+ unsigned long nr_pages)
{
const u64 max_addr = PFN_PHYS(pfn + nr_pages) - 1;
--
2.24.1
^ permalink raw reply related
* Re: [PATCH] evh_bytechan: fix out of bounds accesses
From: Stephen Rothwell @ 2020-02-20 23:57 UTC (permalink / raw)
To: Laurentiu Tudor
Cc: Timur Tabi, b08248, Greg Kroah-Hartman, Jiri Slaby, york sun,
PowerPC Mailing List, Scott Wood
In-Reply-To: <20200116113714.06208a73@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]
Hi all,
On Thu, 16 Jan 2020 11:37:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 15 Jan 2020 14:01:35 -0600 Scott Wood <swood@redhat.com> wrote:
> >
> > On Thu, 2020-01-16 at 06:42 +1100, Stephen Rothwell wrote:
> > > Hi Timur,
> > >
> > > On Wed, 15 Jan 2020 07:25:45 -0600 Timur Tabi <timur@kernel.org> wrote:
> > > > On 1/14/20 12:31 AM, Stephen Rothwell wrote:
> > > > > +/**
> > > > > + * ev_byte_channel_send - send characters to a byte stream
> > > > > + * @handle: byte stream handle
> > > > > + * @count: (input) num of chars to send, (output) num chars sent
> > > > > + * @bp: pointer to chars to send
> > > > > + *
> > > > > + * Returns 0 for success, or an error code.
> > > > > + */
> > > > > +static unsigned int ev_byte_channel_send(unsigned int handle,
> > > > > + unsigned int *count, const char *bp)
> > > >
> > > > Well, now you've moved this into the .c file and it is no longer
> > > > available to other callers. Anything wrong with keeping it in the .h
> > > > file?
> > >
> > > There are currently no other callers - are there likely to be in the
> > > future? Even if there are, is it time critical enough that it needs to
> > > be inlined everywhere?
> >
> > It's not performance critical and there aren't likely to be other users --
> > just a matter of what's cleaner. FWIW I'd rather see the original patch,
> > that keeps the raw asm hcall stuff as simple wrappers in one place.
>
> And I don't mind either way :-)
>
> I just want to get rid of the warnings.
Any progress with this?
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] selftest/lkdtm: Don't pollute 'git status'
From: Kees Cook @ 2020-02-20 23:18 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linux-mm, linuxppc-dev, linux-kernel, Shuah Khan
In-Reply-To: <668b6ff463849ceee01f726fbf3e7110687575ec.1580976576.git.christophe.leroy@c-s.fr>
On Thu, Feb 06, 2020 at 08:11:39AM +0000, Christophe Leroy wrote:
> Commit 46d1a0f03d66 ("selftests/lkdtm: Add tests for LKDTM targets")
> added generation of lkdtm test scripts.
>
> Ignore those generated scripts when performing 'git status'
>
> Fixes: 46d1a0f03d66 ("selftests/lkdtm: Add tests for LKDTM targets")
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Ah! Yes, a very good idea. Thanks!
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> .gitignore | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/.gitignore b/.gitignore
> index b849a72d69d5..bb05dce58f8e 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -100,6 +100,10 @@ modules.order
> /include/ksym/
> /arch/*/include/generated/
>
> +# Generated lkdtm tests
> +/tools/testing/selftests/lkdtm/*.sh
> +!/tools/testing/selftests/lkdtm/run.sh
> +
> # stgit generated dirs
> patches-*
>
> --
> 2.25.0
>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH kernel 5/5] vfio/spapr_tce: Advertise and allow a huge DMA windows at 4GB
From: Alex Williamson @ 2020-02-20 18:19 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: Alistair Popple, linuxppc-dev, kvm-ppc, David Gibson
In-Reply-To: <20200218073650.16149-6-aik@ozlabs.ru>
On Tue, 18 Feb 2020 18:36:50 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> So far the only option for a big 64big DMA window was a window located
> at 0x800.0000.0000.0000 (1<<59) which creates problems for devices
> supporting smaller DMA masks.
>
> This exploits a POWER9 PHB option to allow the second DMA window to map
> at 0 and advertises it with a 4GB offset to avoid overlap with
> the default 32bit window.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> include/uapi/linux/vfio.h | 2 ++
> drivers/vfio/vfio_iommu_spapr_tce.c | 10 ++++++++--
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 9e843a147ead..c7f89d47335a 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -831,9 +831,11 @@ struct vfio_iommu_spapr_tce_info {
> __u32 argsz;
> __u32 flags;
> #define VFIO_IOMMU_SPAPR_INFO_DDW (1 << 0) /* DDW supported */
> +#define VFIO_IOMMU_SPAPR_INFO_DDW_START (1 << 1) /* DDW offset */
> __u32 dma32_window_start; /* 32 bit window start (bytes) */
> __u32 dma32_window_size; /* 32 bit window size (bytes) */
> struct vfio_iommu_spapr_tce_ddw_info ddw;
> + __u64 dma64_window_start;
> };
>
> #define VFIO_IOMMU_SPAPR_TCE_GET_INFO _IO(VFIO_TYPE, VFIO_BASE + 12)
> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
> index 16b3adc508db..4f22be3c4aa2 100644
> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> @@ -691,7 +691,7 @@ static long tce_iommu_create_window(struct tce_container *container,
> container->tables[num] = tbl;
>
> /* Return start address assigned by platform in create_table() */
> - *start_addr = tbl->it_offset << tbl->it_page_shift;
> + *start_addr = tbl->it_dmaoff << tbl->it_page_shift;
>
> return 0;
>
> @@ -842,7 +842,13 @@ static long tce_iommu_ioctl(void *iommu_data,
> info.ddw.levels = table_group->max_levels;
> }
>
> - ddwsz = offsetofend(struct vfio_iommu_spapr_tce_info, ddw);
> + ddwsz = offsetofend(struct vfio_iommu_spapr_tce_info,
> + dma64_window_start);
This breaks existing users, now they no longer get the ddw struct
unless their argsz also includes the new dma64 window field.
> +
> + if (info.argsz >= ddwsz) {
> + info.flags |= VFIO_IOMMU_SPAPR_INFO_DDW_START;
> + info.dma64_window_start = table_group->tce64_start;
> + }
This is inconsistent with ddw where we set the flag regardless of
argsz, but obviously only provide the field to the user if they've
provided room for it. Thanks,
Alex
>
> if (info.argsz >= ddwsz)
> minsz = ddwsz;
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: Fix clearing of bits 20-23 in ITLB miss
From: Leonardo Bras @ 2020-02-20 21:53 UTC (permalink / raw)
To: christophe.leroy, benh, paulus, mpe; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1cd9c970771ba9f08621ae8357340c93f386bc24.camel@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]
On Tue, 2020-02-11 at 01:28 -0300, Leonardo Bras wrote:
> Looks a valid change.
> rlwimi r10, r10, 0, 0x0f00 means:
> r10 = ((r10 << 0) & 0x0f00) | (r10 & ~0x0f00) which ends up being
> r10 = r10
>
> On ISA, rlwinm is recommended for clearing high order bits.
> rlwinm r10, r10, 0, ~0x0f00 means:
> r10 = (r10 << 0) & ~0x0f00
>
> Which does exactly what the comments suggests.
>
> FWIW:
> Reviwed-by: Leonardo Bras <leonardo@linux.ibm.com>
Sorry, I just realized the above was not very clear on my part.
What I meant to say was:
I think your change is correct, as it correctly fixes this line.
I would suggest adding the text bellow to your commit message, making
it easier to understand why rlwimi is not the right instruction clear
bytes 20-23, and why rlwinm is.
The current instruction can be translated to C as:
rlwimi r10, r10, 0, 0x0f00
r10 = ((r10 << 0) & 0x0f00) | (r10 & ~0x0f00) ->
r10 = (r10 & 0x0f00) | (r10 & ~0x0f00) ->
r10 = r10
The new proposed instruction can be translated to C as:
rlwinm r10, r10, 0, ~0x0f00 ->
r10 = (r10 << 0) & ~0x0f00
Which clears bits 20-23 as comment on code states.
Best regards,
Leonardo Bras
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Treat TM-related invalid form instructions on P9 like the valid ones
From: Gustavo Romero @ 2020-02-20 21:40 UTC (permalink / raw)
To: Leonardo Bras, kvm-ppc, paulus; +Cc: mikey, linuxppc-dev
In-Reply-To: <b19a8b0cb1ad8275458df16142756b30f8b288b7.camel@linux.ibm.com>
Hi Leonardo,
Thanks a lot for the review.
On 02/20/2020 02:51 PM, Leonardo Bras wrote:
>> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> +
>
> Could not see where is this used.
This is used by pr_warn_ratelimited() below so the module name is printed before
the message, for instance:
[531454.670909] kvm_hv: Unrecognized TM-related instruction 0x7c00075c for emulation
>> #include <linux/kvm_host.h>
>>
>> #include <asm/kvm_ppc.h>
>> @@ -44,7 +46,18 @@ int kvmhv_p9_tm_emulation(struct kvm_vcpu *vcpu)
>> u64 newmsr, bescr;
>> int ra, rs;
>>
>> - switch (instr & 0xfc0007ff) {
>> + /*
>> + * rfid, rfebb, and mtmsrd encode bit 31 = 0 since it's a reserved bit
>> + * in these instructions, so masking bit 31 out doesn't change these
>> + * instructions. For treclaim., tsr., and trechkpt. instructions if bit
>> + * 31 = 0 then they are per ISA invalid forms, however P9 UM, in section
>> + * 4.6.10 Book II Invalid Forms, informs specifically that ignoring bit
>> + * 31 is an acceptable way to handle these invalid forms that have
>> + * bit 31 = 0. Moreover, for emulation purposes both forms (w/ and wo/
>> + * bit 31 set) can generate a softpatch interrupt. Hence both forms
>> + * are handled below for these instructions so they behave the same way.
>> + */
>> + switch (instr & PO_XOP_OPCODE_MASK) {
>>
> <SNIP>
>> - case PPC_INST_TRECHKPT:
>> + /* ignore bit 31, see comment above */
>> + case (PPC_INST_TRECHKPT & PO_XOP_OPCODE_MASK):
>> /* XXX do we need to check for PR=0 here? */
>> /* check for TM disabled in the HFSCR or MSR */
>> if (!(vcpu->arch.hfscr & HFSCR_TM)) {
>> @@ -208,6 +224,8 @@ int kvmhv_p9_tm_emulation(struct kvm_vcpu *vcpu)
>> }
>>
>
> Seems good, using the same flag to mask out bit 31 of these macros.
> They are used only in a few places, and I think removing the macro bit
> would be ok, but I think your way is better to keep it documented.
>
> I just noticed that there is a similar function that uses PPC_INST_TSR:
> kvmhv_p9_tm_emulation_early @ arch/powerpc/kvm/book3s_hv_tm_builtin.c.
> Wouldn't it need to be changed as well?
oh! you're right, I forgot that one. I'll send a v3.
>> /* What should we do here? We didn't recognize the instruction */
>> - WARN_ON_ONCE(1);
>> + kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
>> + pr_warn_ratelimited("Unrecognized TM-related instruction %#x for emulation", instr);
>> +
>> return RESUME_GUEST;
>> }
>
> I suppose this is the right thing to do, but I think it would be better
> to give this change it's own patch.
>
> What do you think?
I think it's sufficiently self-contained and trivial to be in the same file and
to be in a single commit.
Best regards,
Gustavo
^ permalink raw reply
* Re: [PATCH] selftest/lkdtm: Don't pollute 'git status'
From: Shuah Khan @ 2020-02-20 15:49 UTC (permalink / raw)
To: Christophe Leroy, Kees Cook
Cc: linux-mm, linuxppc-dev, linux-kernel,
open list:KERNEL SELFTEST FRAMEWORK, Shuah Khan
In-Reply-To: <ca71e490-b4fa-bf53-7a60-b6954b9dd33e@c-s.fr>
On 2/20/20 7:58 AM, Christophe Leroy wrote:
> ping
>
> On 02/06/2020 08:11 AM, Christophe Leroy wrote:
>> Commit 46d1a0f03d66 ("selftests/lkdtm: Add tests for LKDTM targets")
>> added generation of lkdtm test scripts.
>>
>> Ignore those generated scripts when performing 'git status'
>>
>> Fixes: 46d1a0f03d66 ("selftests/lkdtm: Add tests for LKDTM targets")
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> Without this, 'git status' now reports the following crap and real
> problems are drowned in the middle, that's annoying.
>
I will pull this in. Please cc linux-kselftest mailing list in the
future.
thanks,
-- Shuah
^ permalink raw reply
* [powerpc:fixes] BUILD SUCCESS 9eb425b2e04e0e3006adffea5bf5f227a896f128
From: kbuild test robot @ 2020-02-20 17:59 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes
branch HEAD: 9eb425b2e04e0e3006adffea5bf5f227a896f128 powerpc/entry: Fix an #if which should be an #ifdef in entry_32.S
elapsed time: 1724m
configs tested: 227
configs skipped: 148
The following configs have been built successfully.
More configs may be tested in the coming days.
arm allmodconfig
arm allnoconfig
arm allyesconfig
arm64 allmodconfig
arm64 allnoconfig
arm64 allyesconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
sparc allyesconfig
sparc64 allmodconfig
s390 allmodconfig
sparc64 allnoconfig
i386 allnoconfig
xtensa common_defconfig
s390 debug_defconfig
sh titan_defconfig
ia64 allyesconfig
riscv nommu_virt_defconfig
h8300 h8300h-sim_defconfig
nios2 3c120_defconfig
h8300 h8s-sim_defconfig
riscv allyesconfig
m68k allmodconfig
openrisc or1ksim_defconfig
um defconfig
ia64 allnoconfig
openrisc simple_smp_defconfig
s390 defconfig
sh sh7785lcr_32bit_defconfig
ia64 alldefconfig
alpha defconfig
nds32 defconfig
riscv defconfig
sparc64 defconfig
i386 alldefconfig
i386 allyesconfig
i386 defconfig
ia64 allmodconfig
ia64 defconfig
c6x allyesconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
xtensa iss_defconfig
csky defconfig
nds32 allnoconfig
h8300 edosk2674_defconfig
m68k m5475evb_defconfig
m68k multi_defconfig
m68k sun3_defconfig
arc allyesconfig
arc defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc allnoconfig
powerpc defconfig
powerpc ppc64_defconfig
powerpc rhel-kconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips allnoconfig
mips allyesconfig
mips fuloong2e_defconfig
mips malta_kvm_defconfig
parisc allnoconfig
parisc allyesconfig
parisc generic-32bit_defconfig
parisc generic-64bit_defconfig
x86_64 randconfig-a001-20200220
x86_64 randconfig-a002-20200220
x86_64 randconfig-a003-20200220
i386 randconfig-a001-20200220
i386 randconfig-a002-20200220
i386 randconfig-a003-20200220
x86_64 randconfig-a001-20200219
x86_64 randconfig-a002-20200219
x86_64 randconfig-a003-20200219
i386 randconfig-a001-20200219
i386 randconfig-a002-20200219
i386 randconfig-a003-20200219
alpha randconfig-a001-20200220
m68k randconfig-a001-20200220
mips randconfig-a001-20200220
nds32 randconfig-a001-20200220
parisc randconfig-a001-20200220
riscv randconfig-a001-20200220
c6x randconfig-a001-20200220
h8300 randconfig-a001-20200220
microblaze randconfig-a001-20200220
nios2 randconfig-a001-20200220
sparc64 randconfig-a001-20200220
c6x randconfig-a001-20200219
h8300 randconfig-a001-20200219
microblaze randconfig-a001-20200219
nios2 randconfig-a001-20200219
sparc64 randconfig-a001-20200219
csky randconfig-a001-20200220
openrisc randconfig-a001-20200220
s390 randconfig-a001-20200220
sh randconfig-a001-20200220
xtensa randconfig-a001-20200220
csky randconfig-a001-20200219
openrisc randconfig-a001-20200219
s390 randconfig-a001-20200219
xtensa randconfig-a001-20200219
x86_64 randconfig-b001-20200219
x86_64 randconfig-b002-20200219
x86_64 randconfig-b003-20200219
i386 randconfig-b001-20200219
i386 randconfig-b002-20200219
i386 randconfig-b003-20200219
x86_64 randconfig-b001-20200220
x86_64 randconfig-b002-20200220
x86_64 randconfig-b003-20200220
i386 randconfig-b001-20200220
i386 randconfig-b002-20200220
i386 randconfig-b003-20200220
x86_64 randconfig-c001-20200220
x86_64 randconfig-c002-20200220
x86_64 randconfig-c003-20200220
i386 randconfig-c001-20200220
i386 randconfig-c002-20200220
i386 randconfig-c003-20200220
x86_64 randconfig-c001-20200219
x86_64 randconfig-c002-20200219
x86_64 randconfig-c003-20200219
i386 randconfig-c001-20200219
i386 randconfig-c002-20200219
i386 randconfig-c003-20200219
x86_64 randconfig-d001-20200220
x86_64 randconfig-d002-20200220
x86_64 randconfig-d003-20200220
i386 randconfig-d001-20200220
i386 randconfig-d002-20200220
i386 randconfig-d003-20200220
x86_64 randconfig-d001-20200219
x86_64 randconfig-d002-20200219
x86_64 randconfig-d003-20200219
i386 randconfig-d001-20200219
i386 randconfig-d002-20200219
i386 randconfig-d003-20200219
x86_64 randconfig-e001-20200220
x86_64 randconfig-e002-20200220
x86_64 randconfig-e003-20200220
i386 randconfig-e001-20200220
i386 randconfig-e002-20200220
i386 randconfig-e003-20200220
x86_64 randconfig-e001-20200219
x86_64 randconfig-e002-20200219
x86_64 randconfig-e003-20200219
i386 randconfig-e001-20200219
i386 randconfig-e002-20200219
i386 randconfig-e003-20200219
x86_64 randconfig-f001-20200219
x86_64 randconfig-f002-20200219
x86_64 randconfig-f003-20200219
i386 randconfig-f001-20200219
i386 randconfig-f002-20200219
i386 randconfig-f003-20200219
x86_64 randconfig-f001-20200220
x86_64 randconfig-f002-20200220
x86_64 randconfig-f003-20200220
i386 randconfig-f001-20200220
i386 randconfig-f002-20200220
i386 randconfig-f003-20200220
x86_64 randconfig-g001-20200219
x86_64 randconfig-g002-20200219
x86_64 randconfig-g003-20200219
i386 randconfig-g001-20200219
i386 randconfig-g002-20200219
i386 randconfig-g003-20200219
x86_64 randconfig-g001-20200220
x86_64 randconfig-g002-20200220
x86_64 randconfig-g003-20200220
i386 randconfig-g001-20200220
i386 randconfig-g002-20200220
i386 randconfig-g003-20200220
x86_64 randconfig-h001-20200219
x86_64 randconfig-h002-20200219
x86_64 randconfig-h003-20200219
i386 randconfig-h001-20200219
i386 randconfig-h002-20200219
i386 randconfig-h003-20200219
x86_64 randconfig-h001-20200220
x86_64 randconfig-h002-20200220
x86_64 randconfig-h003-20200220
i386 randconfig-h001-20200220
i386 randconfig-h002-20200220
i386 randconfig-h003-20200220
arc randconfig-a001-20200220
arm randconfig-a001-20200220
arm64 randconfig-a001-20200220
ia64 randconfig-a001-20200220
powerpc randconfig-a001-20200220
sparc randconfig-a001-20200220
arc randconfig-a001-20200219
arm randconfig-a001-20200219
arm64 randconfig-a001-20200219
ia64 randconfig-a001-20200219
powerpc randconfig-a001-20200219
sparc randconfig-a001-20200219
riscv allmodconfig
riscv allnoconfig
riscv rv32_defconfig
s390 alldefconfig
s390 allnoconfig
s390 allyesconfig
s390 zfcpdump_defconfig
sh allmodconfig
sh allnoconfig
sh rsk7269_defconfig
sparc defconfig
sparc64 allyesconfig
um i386_defconfig
um x86_64_defconfig
x86_64 fedora-25
x86_64 kexec
x86_64 lkp
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 rhel-7.6
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Treat TM-related invalid form instructions on P9 like the valid ones
From: Leonardo Bras @ 2020-02-20 17:51 UTC (permalink / raw)
To: Gustavo Romero, kvm-ppc, paulus; +Cc: mikey, linuxppc-dev
In-Reply-To: <20200218211324.23045-1-gromero@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]
Hello Gustavo, comments inline:
On Tue, 2020-02-18 at 16:13 -0500, Gustavo Romero wrote:
<SNIP>
> diff --git a/arch/powerpc/kvm/book3s_hv_tm.c b/arch/powerpc/kvm/book3s_hv_tm.c
> index 0db937497169..cc90b8b82329 100644
> --- a/arch/powerpc/kvm/book3s_hv_tm.c
> +++ b/arch/powerpc/kvm/book3s_hv_tm.c
> @@ -3,6 +3,8 @@
> * Copyright 2017 Paul Mackerras, IBM Corp. <paulus@au1.ibm.com>
> */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
Could not see where is this used.
> #include <linux/kvm_host.h>
>
> #include <asm/kvm_ppc.h>
> @@ -44,7 +46,18 @@ int kvmhv_p9_tm_emulation(struct kvm_vcpu *vcpu)
> u64 newmsr, bescr;
> int ra, rs;
>
> - switch (instr & 0xfc0007ff) {
> + /*
> + * rfid, rfebb, and mtmsrd encode bit 31 = 0 since it's a reserved bit
> + * in these instructions, so masking bit 31 out doesn't change these
> + * instructions. For treclaim., tsr., and trechkpt. instructions if bit
> + * 31 = 0 then they are per ISA invalid forms, however P9 UM, in section
> + * 4.6.10 Book II Invalid Forms, informs specifically that ignoring bit
> + * 31 is an acceptable way to handle these invalid forms that have
> + * bit 31 = 0. Moreover, for emulation purposes both forms (w/ and wo/
> + * bit 31 set) can generate a softpatch interrupt. Hence both forms
> + * are handled below for these instructions so they behave the same way.
> + */
> + switch (instr & PO_XOP_OPCODE_MASK) {
>
<SNIP>
> - case PPC_INST_TRECHKPT:
> + /* ignore bit 31, see comment above */
> + case (PPC_INST_TRECHKPT & PO_XOP_OPCODE_MASK):
> /* XXX do we need to check for PR=0 here? */
> /* check for TM disabled in the HFSCR or MSR */
> if (!(vcpu->arch.hfscr & HFSCR_TM)) {
> @@ -208,6 +224,8 @@ int kvmhv_p9_tm_emulation(struct kvm_vcpu *vcpu)
> }
>
Seems good, using the same flag to mask out bit 31 of these macros.
They are used only in a few places, and I think removing the macro bit
would be ok, but I think your way is better to keep it documented.
I just noticed that there is a similar function that uses PPC_INST_TSR:
kvmhv_p9_tm_emulation_early @ arch/powerpc/kvm/book3s_hv_tm_builtin.c.
Wouldn't it need to be changed as well?
> /* What should we do here? We didn't recognize the instruction */
> - WARN_ON_ONCE(1);
> + kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
> + pr_warn_ratelimited("Unrecognized TM-related instruction %#x for emulation", instr);
> +
> return RESUME_GUEST;
> }
I suppose this is the right thing to do, but I think it would be better
to give this change it's own patch.
What do you think?
Best regards,
Leonardo Bras
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: MCE handler gets NIP wrong on MPC8378
From: Christophe Leroy @ 2020-02-20 17:48 UTC (permalink / raw)
To: Radu Rendec; +Cc: linuxppc-dev
In-Reply-To: <CAD5jUk9kEsWJDkgOD4rSsL6D2U92FLcunOSu6dVQjR1qdbMQWg@mail.gmail.com>
Le 20/02/2020 à 18:34, Radu Rendec a écrit :
> On 02/20/2020 at 11:25 AM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>> Le 20/02/2020 à 17:02, Radu Rendec a écrit :
>>> On 02/20/2020 at 3:38 AM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>>>> On 02/19/2020 10:39 PM, Radu Rendec wrote:
>>>>> On 02/19/2020 at 4:21 PM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>>>>>>> Interesting.
>>>>>>>
>>>>>>> 0x900 is the adress of the timer interrupt.
>>>>>>>
>>>>>>> Would the MCE occur just after the timer interrupt ?
>>>>>
>>>>> I doubt that. I'm using a small test module to artificially trigger the
>>>>> MCE. Basically it's just this (the full code is in my original post):
>>>>>
>>>>> bad_addr_base = ioremap(0xf0000000, 0x100);
>>>>> x = ioread32(bad_addr_base);
>>>>>
>>>>> I find it hard to believe that every time I load the module the lwbrx
>>>>> instruction that triggers the MCE is executed exactly after the timer
>>>>> interrupt (or that the timer interrupt always occurs close to the lwbrx
>>>>> instruction).
>>>>
>>>> Can you try to see how much time there is between your read and the MCE ?
>>>> The below should allow it, you'll see first value in r13 and the other
>>>> in r14 (mce.c is your test code)
>>>>
>>>> Also provide the timebase frequency as reported in /proc/cpuinfo
>>>
>>> I just ran a test: r13 is 0xda8e0f91 and r14 is 0xdaae0f9c.
>>>
>>> # cat /proc/cpuinfo
>>> processor : 0
>>> cpu : e300c4
>>> clock : 800.000004MHz
>>> revision : 1.1 (pvr 8086 1011)
>>> bogomips : 200.00
>>> timebase : 100000000
>>>
>>> The difference between r14 and r13 is 0x20000b. Assuming TB is
>>> incremented with 'timebase' frequency, that means 20.97 milliseconds
>>> (although the e300 manual says TB is "incremented once every four core
>>> input clock cycles").
>>
>> I wouldn't be surprised that the internal CPU clock be twice the input
>> clock.
>>
>> So that's long enough to surely get a timer interrupt during every bad
>> access.
>>
>> Now we have to understand why SRR1 contains the address of the timer
>> exception entry and not the address of the bad access.
>>
>> The value of SRR1 confirms that it comes from 0x900 as MSR[IR] and [DR]
>> are cleared when interrupts are enabled.
>>
>> Maybe you should file a support case at NXP. They are usually quite
>> professionnal at responding.
>
> I already did (quite some time ago), but it started off as "why does the
> MCE occur in the first place". That part has already been figured out,
> but unfortunately I don't have a viable solution to it. Like you said,
> now the focus has shifted to understanding why the SRR0 value is not
> what we expect.
>
> I asked them the question about SRR0 as soon as you helped me get back
> on track and figured out there's nothing wrong with the Linux MCE
> handler and the NIP value comes from SRR0. What they came up with is
> basically this paragraph in the e300 core manual (section 5.5.2):
>
> | Note that the e300 core makes no attempt to force recoverability on a
> | machine check; however, it does guarantee that the machine check
> | interrupt is always taken immediately upon request, with a nonpredicted
> | address saved in SRR0, regardless of the current machine state.
>
> ... and with an emphasis on "nonpredicted". To be honest, I am a bit
> disappointed with their response and I believe in this context what
> "unpredicted" means is that the address that is saved to SRR0 is a
> "real" address rather than the result of branch prediction. The support
> folks were probably thinking "unpredictable". But that's another word
> and the difference is quite subtle :)
>
> I updated the case and added information about the interrupts and the
> timing. Let's see what they come up with this time.
>
Yes now the point is to understand why it starts processing the timer
interrupt at 0x900 (with IR and DR cleared as observed in SRR1) just
before taking the Machine Check.
Allthough the execution of the decrementer interrupt is queue for after
the completion of the failing memory access, I'd expect the Machine
Check to take priority.
Note that I have never observed such a behaviour on MPC8321 which has an
e300c2 core.
Christophe
^ permalink raw reply
* Re: MCE handler gets NIP wrong on MPC8378
From: Radu Rendec @ 2020-02-20 17:34 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev
In-Reply-To: <8008403c-49cd-29bc-712d-2e13b601041c@c-s.fr>
On 02/20/2020 at 11:25 AM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> Le 20/02/2020 à 17:02, Radu Rendec a écrit :
> > On 02/20/2020 at 3:38 AM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> >> On 02/19/2020 10:39 PM, Radu Rendec wrote:
> >>> On 02/19/2020 at 4:21 PM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> >>>>> Interesting.
> >>>>>
> >>>>> 0x900 is the adress of the timer interrupt.
> >>>>>
> >>>>> Would the MCE occur just after the timer interrupt ?
> >>>
> >>> I doubt that. I'm using a small test module to artificially trigger the
> >>> MCE. Basically it's just this (the full code is in my original post):
> >>>
> >>> bad_addr_base = ioremap(0xf0000000, 0x100);
> >>> x = ioread32(bad_addr_base);
> >>>
> >>> I find it hard to believe that every time I load the module the lwbrx
> >>> instruction that triggers the MCE is executed exactly after the timer
> >>> interrupt (or that the timer interrupt always occurs close to the lwbrx
> >>> instruction).
> >>
> >> Can you try to see how much time there is between your read and the MCE ?
> >> The below should allow it, you'll see first value in r13 and the other
> >> in r14 (mce.c is your test code)
> >>
> >> Also provide the timebase frequency as reported in /proc/cpuinfo
> >
> > I just ran a test: r13 is 0xda8e0f91 and r14 is 0xdaae0f9c.
> >
> > # cat /proc/cpuinfo
> > processor : 0
> > cpu : e300c4
> > clock : 800.000004MHz
> > revision : 1.1 (pvr 8086 1011)
> > bogomips : 200.00
> > timebase : 100000000
> >
> > The difference between r14 and r13 is 0x20000b. Assuming TB is
> > incremented with 'timebase' frequency, that means 20.97 milliseconds
> > (although the e300 manual says TB is "incremented once every four core
> > input clock cycles").
>
> I wouldn't be surprised that the internal CPU clock be twice the input
> clock.
>
> So that's long enough to surely get a timer interrupt during every bad
> access.
>
> Now we have to understand why SRR1 contains the address of the timer
> exception entry and not the address of the bad access.
>
> The value of SRR1 confirms that it comes from 0x900 as MSR[IR] and [DR]
> are cleared when interrupts are enabled.
>
> Maybe you should file a support case at NXP. They are usually quite
> professionnal at responding.
I already did (quite some time ago), but it started off as "why does the
MCE occur in the first place". That part has already been figured out,
but unfortunately I don't have a viable solution to it. Like you said,
now the focus has shifted to understanding why the SRR0 value is not
what we expect.
I asked them the question about SRR0 as soon as you helped me get back
on track and figured out there's nothing wrong with the Linux MCE
handler and the NIP value comes from SRR0. What they came up with is
basically this paragraph in the e300 core manual (section 5.5.2):
| Note that the e300 core makes no attempt to force recoverability on a
| machine check; however, it does guarantee that the machine check
| interrupt is always taken immediately upon request, with a nonpredicted
| address saved in SRR0, regardless of the current machine state.
... and with an emphasis on "nonpredicted". To be honest, I am a bit
disappointed with their response and I believe in this context what
"unpredicted" means is that the address that is saved to SRR0 is a
"real" address rather than the result of branch prediction. The support
folks were probably thinking "unpredictable". But that's another word
and the difference is quite subtle :)
I updated the case and added information about the interrupts and the
timing. Let's see what they come up with this time.
Best regards,
Radu
^ permalink raw reply
* Re: MCE handler gets NIP wrong on MPC8378
From: Christophe Leroy @ 2020-02-20 16:25 UTC (permalink / raw)
To: Radu Rendec; +Cc: linuxppc-dev
In-Reply-To: <CAD5jUk_L0tmy-2YwC9pZA=PXTeVLhq64emF3J5Vz=mVP_VHZ_w@mail.gmail.com>
Le 20/02/2020 à 17:02, Radu Rendec a écrit :
> On 02/20/2020 at 3:38 AM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>> On 02/19/2020 10:39 PM, Radu Rendec wrote:
>>> On 02/19/2020 at 4:21 PM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>>>>> Interesting.
>>>>>
>>>>> 0x900 is the adress of the timer interrupt.
>>>>>
>>>>> Would the MCE occur just after the timer interrupt ?
>>>
>>> I doubt that. I'm using a small test module to artificially trigger the
>>> MCE. Basically it's just this (the full code is in my original post):
>>>
>>> bad_addr_base = ioremap(0xf0000000, 0x100);
>>> x = ioread32(bad_addr_base);
>>>
>>> I find it hard to believe that every time I load the module the lwbrx
>>> instruction that triggers the MCE is executed exactly after the timer
>>> interrupt (or that the timer interrupt always occurs close to the lwbrx
>>> instruction).
>>
>> Can you try to see how much time there is between your read and the MCE ?
>> The below should allow it, you'll see first value in r13 and the other
>> in r14 (mce.c is your test code)
>>
>> Also provide the timebase frequency as reported in /proc/cpuinfo
>
> I just ran a test: r13 is 0xda8e0f91 and r14 is 0xdaae0f9c.
>
> # cat /proc/cpuinfo
> processor : 0
> cpu : e300c4
> clock : 800.000004MHz
> revision : 1.1 (pvr 8086 1011)
> bogomips : 200.00
> timebase : 100000000
>
> The difference between r14 and r13 is 0x20000b. Assuming TB is
> incremented with 'timebase' frequency, that means 20.97 milliseconds
> (although the e300 manual says TB is "incremented once every four core
> input clock cycles").
I wouldn't be surprised that the internal CPU clock be twice the input
clock.
So that's long enough to surely get a timer interrupt during every bad
access.
Now we have to understand why SRR1 contains the address of the timer
exception entry and not the address of the bad access.
The value of SRR1 confirms that it comes from 0x900 as MSR[IR] and [DR]
are cleared when interrupts are enabled.
Maybe you should file a support case at NXP. They are usually quite
professionnal at responding.
Christophe
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.5 096/542] powerpc/powernv/ioda: Fix ref count for devices with their own PE
From: Sasha Levin @ 2020-02-20 16:12 UTC (permalink / raw)
To: Frederic Barrat; +Cc: linuxppc-dev, linux-kernel, stable, Andrew Donnellan
In-Reply-To: <0867167a-73b8-0735-78ce-0d984f7a80b5@linux.ibm.com>
On Mon, Feb 17, 2020 at 09:49:41AM +0100, Frederic Barrat wrote:
>
>
>Le 14/02/2020 à 16:41, Sasha Levin a écrit :
>>From: Frederic Barrat <fbarrat@linux.ibm.com>
>>
>>[ Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 ]
>
>
>Hi,
>
>Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 doesn't
>really need to go to stable (any of 4.19, 5.4 and 5.5). While it's
>probably safe, the patch replaces a refcount leak by another one,
>which makes sense as part of the full series merged in 5.6-rc1, but
>isn't terribly useful standalone on the current stable branches.
I'll drop it, thank you.
--
Thanks,
Sasha
^ permalink raw reply
* Re: MCE handler gets NIP wrong on MPC8378
From: Radu Rendec @ 2020-02-20 16:02 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev
In-Reply-To: <09e9a042-766c-d2e6-2300-cebc372cabde@c-s.fr>
On 02/20/2020 at 3:38 AM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> On 02/19/2020 10:39 PM, Radu Rendec wrote:
> > On 02/19/2020 at 4:21 PM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> >>> Interesting.
> >>>
> >>> 0x900 is the adress of the timer interrupt.
> >>>
> >>> Would the MCE occur just after the timer interrupt ?
> >
> > I doubt that. I'm using a small test module to artificially trigger the
> > MCE. Basically it's just this (the full code is in my original post):
> >
> > bad_addr_base = ioremap(0xf0000000, 0x100);
> > x = ioread32(bad_addr_base);
> >
> > I find it hard to believe that every time I load the module the lwbrx
> > instruction that triggers the MCE is executed exactly after the timer
> > interrupt (or that the timer interrupt always occurs close to the lwbrx
> > instruction).
>
> Can you try to see how much time there is between your read and the MCE ?
> The below should allow it, you'll see first value in r13 and the other
> in r14 (mce.c is your test code)
>
> Also provide the timebase frequency as reported in /proc/cpuinfo
I just ran a test: r13 is 0xda8e0f91 and r14 is 0xdaae0f9c.
# cat /proc/cpuinfo
processor : 0
cpu : e300c4
clock : 800.000004MHz
revision : 1.1 (pvr 8086 1011)
bogomips : 200.00
timebase : 100000000
The difference between r14 and r13 is 0x20000b. Assuming TB is
incremented with 'timebase' frequency, that means 20.97 milliseconds
(although the e300 manual says TB is "incremented once every four core
input clock cycles").
I repeated the test twice and the absolute values were of course very
different, but r14-r13 was 0x20000c and 0x200011, so it seems to be
quite consistent (within just a few clock cycles).
Just for the fun of it, I repeated the test once more, but with
interrupts disabled. The difference was 0x200014. FWIW, I disabled
interrupts before sampling TB in r13.
> And what's the reason given in the Oops message for the machine check ?
> Is that "Caused by (from SRR1=49030): Transfer error ack signal" or
> something else ?
When interrupts are enabled:
Caused by (from SRR1=41000): Transfer error ack signal
When interrupts are disabled:
Caused by (from SRR1=41030): Transfer error ack signal
> >
> >> Do you use the local bus monitoring driver ?
> >
> > I don't. In fact, I'm not even aware of it. What driver is that?
>
> CONFIG_FSL_LBC
OK, it seems I'm actually using it. I haven't enabled it explicitly, but
it's automatically pulled by CONFIG_MTD_NAND_FSL_ELBC as a prerequisite.
I looked at the code in arch/powerpc/sysdev/fsl_lbc.c and it's quite
small. Most of the code is in fsl_lbc_ctrl_irq, which I guess is
supposed to print a message if/when the LBC catches an error. I've never
seen any of those messages being printed.
Best regards,
Radu
^ permalink raw reply
* Re: [PATCH] selftest/lkdtm: Don't pollute 'git status'
From: Christophe Leroy @ 2020-02-20 14:58 UTC (permalink / raw)
To: Kees Cook, Shuah Khan; +Cc: linux-mm, linuxppc-dev, linux-kernel
In-Reply-To: <668b6ff463849ceee01f726fbf3e7110687575ec.1580976576.git.christophe.leroy@c-s.fr>
ping
On 02/06/2020 08:11 AM, Christophe Leroy wrote:
> Commit 46d1a0f03d66 ("selftests/lkdtm: Add tests for LKDTM targets")
> added generation of lkdtm test scripts.
>
> Ignore those generated scripts when performing 'git status'
>
> Fixes: 46d1a0f03d66 ("selftests/lkdtm: Add tests for LKDTM targets")
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Without this, 'git status' now reports the following crap and real
problems are drowned in the middle, that's annoying.
On branch saf3000-5.6
Untracked files:
(use "git add <file>..." to include in what will be committed)
tools/testing/selftests/lkdtm/ACCESS_NULL.sh
tools/testing/selftests/lkdtm/ACCESS_USERSPACE.sh
tools/testing/selftests/lkdtm/ATOMIC_TIMING.sh
tools/testing/selftests/lkdtm/BUG.sh
tools/testing/selftests/lkdtm/CFI_FORWARD_PROTO.sh
tools/testing/selftests/lkdtm/CORRUPT_LIST_ADD.sh
tools/testing/selftests/lkdtm/CORRUPT_LIST_DEL.sh
tools/testing/selftests/lkdtm/CORRUPT_STACK.sh
tools/testing/selftests/lkdtm/CORRUPT_STACK_STRONG.sh
tools/testing/selftests/lkdtm/CORRUPT_USER_DS.sh
tools/testing/selftests/lkdtm/DOUBLE_FAULT.sh
tools/testing/selftests/lkdtm/EXCEPTION.sh
tools/testing/selftests/lkdtm/EXEC_DATA.sh
tools/testing/selftests/lkdtm/EXEC_KMALLOC.sh
tools/testing/selftests/lkdtm/EXEC_NULL.sh
tools/testing/selftests/lkdtm/EXEC_RODATA.sh
tools/testing/selftests/lkdtm/EXEC_STACK.sh
tools/testing/selftests/lkdtm/EXEC_USERSPACE.sh
tools/testing/selftests/lkdtm/EXEC_VMALLOC.sh
tools/testing/selftests/lkdtm/EXHAUST_STACK.sh
tools/testing/selftests/lkdtm/HARDLOCKUP.sh
tools/testing/selftests/lkdtm/HUNG_TASK.sh
tools/testing/selftests/lkdtm/LOOP.sh
tools/testing/selftests/lkdtm/OVERWRITE_ALLOCATION.sh
tools/testing/selftests/lkdtm/PANIC.sh
tools/testing/selftests/lkdtm/READ_AFTER_FREE.sh
tools/testing/selftests/lkdtm/READ_BUDDY_AFTER_FREE.sh
tools/testing/selftests/lkdtm/REFCOUNT_ADD_NOT_ZERO_OVERFLOW.sh
tools/testing/selftests/lkdtm/REFCOUNT_ADD_NOT_ZERO_SATURATED.sh
tools/testing/selftests/lkdtm/REFCOUNT_ADD_OVERFLOW.sh
tools/testing/selftests/lkdtm/REFCOUNT_ADD_SATURATED.sh
tools/testing/selftests/lkdtm/REFCOUNT_ADD_ZERO.sh
tools/testing/selftests/lkdtm/REFCOUNT_DEC_AND_TEST_NEGATIVE.sh
tools/testing/selftests/lkdtm/REFCOUNT_DEC_AND_TEST_SATURATED.sh
tools/testing/selftests/lkdtm/REFCOUNT_DEC_NEGATIVE.sh
tools/testing/selftests/lkdtm/REFCOUNT_DEC_SATURATED.sh
tools/testing/selftests/lkdtm/REFCOUNT_DEC_ZERO.sh
tools/testing/selftests/lkdtm/REFCOUNT_INC_NOT_ZERO_OVERFLOW.sh
tools/testing/selftests/lkdtm/REFCOUNT_INC_NOT_ZERO_SATURATED.sh
tools/testing/selftests/lkdtm/REFCOUNT_INC_OVERFLOW.sh
tools/testing/selftests/lkdtm/REFCOUNT_INC_SATURATED.sh
tools/testing/selftests/lkdtm/REFCOUNT_INC_ZERO.sh
tools/testing/selftests/lkdtm/REFCOUNT_SUB_AND_TEST_NEGATIVE.sh
tools/testing/selftests/lkdtm/REFCOUNT_SUB_AND_TEST_SATURATED.sh
tools/testing/selftests/lkdtm/REFCOUNT_TIMING.sh
tools/testing/selftests/lkdtm/SLAB_FREE_CROSS.sh
tools/testing/selftests/lkdtm/SLAB_FREE_DOUBLE.sh
tools/testing/selftests/lkdtm/SLAB_FREE_PAGE.sh
tools/testing/selftests/lkdtm/SOFTLOCKUP.sh
tools/testing/selftests/lkdtm/SPINLOCKUP.sh
tools/testing/selftests/lkdtm/STACKLEAK_ERASING.sh
tools/testing/selftests/lkdtm/STACK_GUARD_PAGE_LEADING.sh
tools/testing/selftests/lkdtm/STACK_GUARD_PAGE_TRAILING.sh
tools/testing/selftests/lkdtm/UNALIGNED_LOAD_STORE_WRITE.sh
tools/testing/selftests/lkdtm/UNSET_SMEP.sh
tools/testing/selftests/lkdtm/USERCOPY_HEAP_SIZE_FROM.sh
tools/testing/selftests/lkdtm/USERCOPY_HEAP_SIZE_TO.sh
tools/testing/selftests/lkdtm/USERCOPY_HEAP_WHITELIST_FROM.sh
tools/testing/selftests/lkdtm/USERCOPY_HEAP_WHITELIST_TO.sh
tools/testing/selftests/lkdtm/USERCOPY_KERNEL.sh
tools/testing/selftests/lkdtm/USERCOPY_KERNEL_DS.sh
tools/testing/selftests/lkdtm/USERCOPY_STACK_BEYOND.sh
tools/testing/selftests/lkdtm/USERCOPY_STACK_FRAME_FROM.sh
tools/testing/selftests/lkdtm/USERCOPY_STACK_FRAME_TO.sh
tools/testing/selftests/lkdtm/WARNING.sh
tools/testing/selftests/lkdtm/WARNING_MESSAGE.sh
tools/testing/selftests/lkdtm/WRITE_AFTER_FREE.sh
tools/testing/selftests/lkdtm/WRITE_BUDDY_AFTER_FREE.sh
tools/testing/selftests/lkdtm/WRITE_KERN.sh
tools/testing/selftests/lkdtm/WRITE_RO.sh
tools/testing/selftests/lkdtm/WRITE_RO_AFTER_INIT.sh
nothing added to commit but untracked files present (use "git add" to track)
Thanks
Christophe
> ---
> .gitignore | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/.gitignore b/.gitignore
> index b849a72d69d5..bb05dce58f8e 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -100,6 +100,10 @@ modules.order
> /include/ksym/
> /arch/*/include/generated/
>
> +# Generated lkdtm tests
> +/tools/testing/selftests/lkdtm/*.sh
> +!/tools/testing/selftests/lkdtm/run.sh
> +
> # stgit generated dirs
> patches-*
>
>
^ permalink raw reply
* Re: [PATCH v3 6/6] powerpc/fsl_booke/kaslr: rename kaslr-booke32.rst to kaslr-booke.rst and add 64bit part
From: Christophe Leroy @ 2020-02-20 13:50 UTC (permalink / raw)
To: Jason Yan, mpe, linuxppc-dev, diana.craciun, benh, paulus,
npiggin, keescook, kernel-hardening, oss
Cc: linux-kernel, zhaohongjiang
In-Reply-To: <20200206025825.22934-7-yanaijie@huawei.com>
Le 06/02/2020 à 03:58, Jason Yan a écrit :
> Now we support both 32 and 64 bit KASLR for fsl booke. Add document for
> 64 bit part and rename kaslr-booke32.rst to kaslr-booke.rst.
>
> Signed-off-by: Jason Yan <yanaijie@huawei.com>
> Cc: Scott Wood <oss@buserror.net>
> Cc: Diana Craciun <diana.craciun@nxp.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Kees Cook <keescook@chromium.org>
> ---
> .../{kaslr-booke32.rst => kaslr-booke.rst} | 35 ++++++++++++++++---
> 1 file changed, 31 insertions(+), 4 deletions(-)
> rename Documentation/powerpc/{kaslr-booke32.rst => kaslr-booke.rst} (59%)
Also update Documentation/powerpc/index.rst ?
Christophe
^ permalink raw reply
* Re: [PATCH v3 5/6] powerpc/fsl_booke/64: clear the original kernel if randomized
From: Christophe Leroy @ 2020-02-20 13:49 UTC (permalink / raw)
To: Jason Yan, mpe, linuxppc-dev, diana.craciun, benh, paulus,
npiggin, keescook, kernel-hardening, oss
Cc: linux-kernel, zhaohongjiang
In-Reply-To: <20200206025825.22934-6-yanaijie@huawei.com>
Le 06/02/2020 à 03:58, Jason Yan a écrit :
> The original kernel still exists in the memory, clear it now.
No such problem with PPC32 ? Or is that common ?
Christophe
>
> Signed-off-by: Jason Yan <yanaijie@huawei.com>
> Cc: Scott Wood <oss@buserror.net>
> Cc: Diana Craciun <diana.craciun@nxp.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Kees Cook <keescook@chromium.org>
> ---
> arch/powerpc/mm/nohash/kaslr_booke.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/nohash/kaslr_booke.c b/arch/powerpc/mm/nohash/kaslr_booke.c
> index c6f5c1db1394..ed1277059368 100644
> --- a/arch/powerpc/mm/nohash/kaslr_booke.c
> +++ b/arch/powerpc/mm/nohash/kaslr_booke.c
> @@ -378,8 +378,10 @@ notrace void __init kaslr_early_init(void *dt_ptr, phys_addr_t size)
> unsigned int *__kaslr_offset = (unsigned int *)(KERNELBASE + 0x58);
> unsigned int *__run_at_load = (unsigned int *)(KERNELBASE + 0x5c);
>
> - if (*__run_at_load == 1)
> + if (*__run_at_load == 1) {
> + kaslr_late_init();
> return;
> + }
>
> /* Setup flat device-tree pointer */
> initial_boot_params = dt_ptr;
>
^ 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