Re: [PATCH 02/10] soc: samsung: convert to devm_platform_ioremap_resource

2019-12-15 Thread Krzysztof Kozlowski
On Sat, Dec 14, 2019 at 05:54:39PM +, Yangtao Li wrote:
> Use devm_platform_ioremap_resource() to simplify code.
> 
> Signed-off-by: Yangtao Li 
> ---
>  drivers/soc/samsung/exynos-pmu.c | 4 +---

Thanks, applied.

Best regards,
Krzysztof



Re: [PATCH 10/10] soc: qcom: convert to devm_platform_ioremap_resource

2019-12-15 Thread Frank Lee
On Sun, Dec 15, 2019 at 6:48 PM Marc Zyngier  wrote:
>
> On Sat, 14 Dec 2019 17:54:47 +
> Yangtao Li  wrote:
>
> > Use devm_platform_ioremap_resource() to simplify code.
> >
> > Signed-off-by: Yangtao Li 
> > ---
> >  drivers/soc/qcom/llcc-qcom.c| 7 +--
> >  drivers/soc/qcom/qcom-geni-se.c | 4 +---
> >  drivers/soc/qcom/qcom_aoss.c| 4 +---
> >  drivers/soc/qcom/qcom_gsbi.c| 5 +
> >  drivers/soc/qcom/spm.c  | 4 +---
> >  5 files changed, 5 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c
> > index 429b5a60a1ba..99e19df76889 100644
> > --- a/drivers/soc/qcom/llcc-qcom.c
> > +++ b/drivers/soc/qcom/llcc-qcom.c
> > @@ -387,7 +387,6 @@ static int qcom_llcc_remove(struct platform_device 
> > *pdev)
> >  static struct regmap *qcom_llcc_init_mmio(struct platform_device *pdev,
> >   const char *name)
> >  {
> > - struct resource *res;
> >   void __iomem *base;
> >   struct regmap_config llcc_regmap_config = {
> >   .reg_bits = 32,
> > @@ -396,11 +395,7 @@ static struct regmap *qcom_llcc_init_mmio(struct 
> > platform_device *pdev,
> >   .fast_io = true,
> >   };
> >
> > - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
> > - if (!res)
> > - return ERR_PTR(-ENODEV);
> > -
> > - base = devm_ioremap_resource(&pdev->dev, res);
> > + base = devm_platform_ioremap_resource(pdev, 0);
>
> What guarantees do you have that entry 0 matches name?

Yeah, this place is wrong. I intruduce another helper.

https://lore.kernel.org/patchwork/patch/1165186/

Thx,
Yangtao


>
> I find these changes pointless: they don't add much to the readability
> or maintainability of the code, and instead introduce creative bugs.
>
> M.
> --
> Jazz is not dead. It just smells funny...


[PATCH 00/10] crypto/nx: Enable GZIP engine and provide userpace API

2019-12-15 Thread Haren Myneni


Power9 processor supports Virtual Accelerator Switchboard (VAS) which
allows kernel and userspace to send compression requests to Nest
Accelerator (NX) directly. The NX unit comprises of 2 842 compression
engines and 1 GZIP engine. Linux kernel already has 842 compression
support on kernel. This patch series adds GZIP compression support
from user space. The GZIP Compression engine implements the ZLIB and
GZIP compression algorithms. No plans of adding NX-GZIP compression
support in kernel right now.

Applications can send requests to NX directly with COPY/PASTE
instructions. But kernel has to establish channel / window on NX-GZIP
device for the userspace. So userspace access to the GZIP engine is
provided through /dev/crypto/nx-gzip device with several several
operations.

An application must open the this device to obtain a file descriptor (fd).
Using the fd, application should issue the VAS_TX_WIN_OPEN ioctl to
establish a connection to the engine. Once window is opened, should use
mmap() system call to map the hardware address of engine's request queue
into the application's virtual address space. Then user space forms the
request as co-processor Request Block (CRB) and paste this CRB on the
mapped HW address using COPY/PASTE instructions. Application can poll
on status flags (part of CRB) with timeout for request completion.

For VAS_TX_WIN_OPEN ioctl, if user space passes vas_id = -1 (struct
vas_tx_win_open_attr), kernel determins the VAS instance on the
corresponding chip based on the CPU on which the process is executing.
Otherwise, the specified VAS instance is used if application passes the
proper VAS instance (vas_id listed in /proc/device-tree/vas@*/ibm,vas_id).

Process can open multiple windows with different FDs or can send several
requests to NX on the same window at the same time.

A userspace library libnxz is available:
https://github.com/abalib/power-gzip

Applications that use inflate/deflate calls can link with libNXz and use
NX GZIP compression without any modification.

Tested the available 842 compression on power8 and power9 system to make
sure no regression and tested GZIP compression on power9 with tests
available in the above link.

Thanks to Bulent Abali for nxz library and tests development.

Haren Myneni (10):
  powerpc/vas: Define vas_win_paste_addr()
  powerpc/vas: Initialize window attributes for GZIP coprocessor type
  powerpc/vas: Define VAS_TX_WIN_OPEN ioctl API
  crypto/nx: Initialize coproc entry with kzalloc
  crypto/nx: Organize powernv 842 code to add new GZIP compression type
  crypto/NX: Make code generic to add new GZIP compression type
  crypto/nx: Enable and setup GZIP compresstion type
  crypto/NX: Add NX GZIP user space API
  powerpc/vas: Remove 'pid' in vas_tx_win_attr struct
  Documentation/powerpc: VAS API

 Documentation/ioctl/ioctl-number.rst|   1 +
 Documentation/powerpc/index.rst |   1 +
 Documentation/powerpc/vas-api.rst   | 246 +++
 arch/powerpc/include/asm/vas.h  |   6 +-
 arch/powerpc/include/uapi/asm/vas-api.h |  22 ++
 arch/powerpc/platforms/powernv/vas-window.c |  27 +-
 drivers/crypto/nx/Makefile  |   2 +-
 drivers/crypto/nx/nx-842-powernv.c  | 412 +---
 drivers/crypto/nx/nx-842-powernv.h  |  31 ++
 drivers/crypto/nx/nx-commom-powernv.c   | 474 
 drivers/crypto/nx/nx-gzip-powernv.c | 282 +
 11 files changed, 1094 insertions(+), 410 deletions(-)
 create mode 100644 Documentation/powerpc/vas-api.rst
 create mode 100644 arch/powerpc/include/uapi/asm/vas-api.h
 create mode 100644 drivers/crypto/nx/nx-842-powernv.h
 create mode 100644 drivers/crypto/nx/nx-commom-powernv.c
 create mode 100644 drivers/crypto/nx/nx-gzip-powernv.c

-- 
1.8.3.1





[PATCH 01/10] powerpc/vas: Define vas_win_paste_addr()

2019-12-15 Thread Haren Myneni


Define an interface that the NX drivers can use to find the physical
paste address of a send window. This interface is expected to be used
with the mmap() operation of the NX driver's device. i.e the user space
process can use driver's mmap() operation to map the send window's paste
address into their address space and then use copy and paste instructions
to submit the CRBs to the NX engine.

Signed-off-by: Sukadev Bhattiprolu 
Signed-off-by: Haren Myneni 
---
 arch/powerpc/include/asm/vas.h  |  5 +
 arch/powerpc/platforms/powernv/vas-window.c | 10 ++
 2 files changed, 15 insertions(+)

diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h
index f93e6b0..6d9e692 100644
--- a/arch/powerpc/include/asm/vas.h
+++ b/arch/powerpc/include/asm/vas.h
@@ -163,4 +163,9 @@ struct vas_window *vas_tx_win_open(int vasid, enum 
vas_cop_type cop,
  */
 int vas_paste_crb(struct vas_window *win, int offset, bool re);
 
+/*
+ * Return the power bus paste address associated with @win so the caller
+ * can map that address into their address space.
+ */
+extern u64 vas_win_paste_addr(struct vas_window *win);
 #endif /* __ASM_POWERPC_VAS_H */
diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 5322d1c..b51eac5 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -42,6 +42,16 @@ static void compute_paste_address(struct vas_window *window, 
u64 *addr, int *len
pr_debug("Txwin #%d: Paste addr 0x%llx\n", winid, *addr);
 }
 
+u64 vas_win_paste_addr(struct vas_window *win)
+{
+   u64 addr;
+
+   compute_paste_address(win, &addr, NULL);
+
+   return addr;
+}
+EXPORT_SYMBOL(vas_win_paste_addr);
+
 static inline void get_hvwc_mmio_bar(struct vas_window *window,
u64 *start, int *len)
 {
-- 
1.8.3.1





[PATCH 02/10] powerpc/vas: Initialize window attributes for GZIP compression

2019-12-15 Thread Haren Myneni


Initialize send and receive window attributes for GZIP high and
normal priority types.

Signed-off-by: Haren Myneni 
---
 arch/powerpc/platforms/powernv/vas-window.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index b51eac5..cc0f530 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -827,7 +827,8 @@ void vas_init_rx_win_attr(struct vas_rx_win_attr *rxattr, 
enum vas_cop_type cop)
 {
memset(rxattr, 0, sizeof(*rxattr));
 
-   if (cop == VAS_COP_TYPE_842 || cop == VAS_COP_TYPE_842_HIPRI) {
+   if (cop == VAS_COP_TYPE_842 || cop == VAS_COP_TYPE_842_HIPRI ||
+   cop == VAS_COP_TYPE_GZIP || cop == VAS_COP_TYPE_GZIP_HIPRI) {
rxattr->pin_win = true;
rxattr->nx_win = true;
rxattr->fault_win = false;
@@ -903,7 +904,8 @@ void vas_init_tx_win_attr(struct vas_tx_win_attr *txattr, 
enum vas_cop_type cop)
 {
memset(txattr, 0, sizeof(*txattr));
 
-   if (cop == VAS_COP_TYPE_842 || cop == VAS_COP_TYPE_842_HIPRI) {
+   if (cop == VAS_COP_TYPE_842 || cop == VAS_COP_TYPE_842_HIPRI ||
+   cop == VAS_COP_TYPE_GZIP || cop == VAS_COP_TYPE_GZIP_HIPRI) {
txattr->rej_no_credit = false;
txattr->rx_wcred_mode = true;
txattr->tx_wcred_mode = true;
@@ -987,9 +989,14 @@ static bool tx_win_args_valid(enum vas_cop_type cop,
if (attr->wcreds_max > VAS_TX_WCREDS_MAX)
return false;
 
-   if (attr->user_win &&
-   (cop != VAS_COP_TYPE_FTW || attr->rsvd_txbuf_count))
-   return false;
+   if (attr->user_win) {
+   if (attr->rsvd_txbuf_count)
+   return false;
+
+   if (cop != VAS_COP_TYPE_FTW && cop != VAS_COP_TYPE_GZIP &&
+   cop != VAS_COP_TYPE_GZIP_HIPRI)
+   return false;
+   }
 
return true;
 }
-- 
1.8.3.1





[PATCH 03/10] powerpc/vas: Define VAS_TX_WIN_OPEN ioctl API

2019-12-15 Thread Haren Myneni


Define the VAS_TX_WIN_OPEN ioctl interface for NX GZIP access
from user space. This interface is used to open GZIP send window and
mmap region which can be used by userspace to send requests to NX
directly with copy/paste instructions.

Signed-off-by: Haren Myneni 
---
 Documentation/ioctl/ioctl-number.rst|  1 +
 arch/powerpc/include/uapi/asm/vas-api.h | 22 ++
 2 files changed, 23 insertions(+)
 create mode 100644 arch/powerpc/include/uapi/asm/vas-api.h

diff --git a/Documentation/ioctl/ioctl-number.rst 
b/Documentation/ioctl/ioctl-number.rst
index bef79cd..dcfc3fa 100644
--- a/Documentation/ioctl/ioctl-number.rst
+++ b/Documentation/ioctl/ioctl-number.rst
@@ -287,6 +287,7 @@ Code  Seq#Include File  
 Comments
 'v'   00-1F  linux/fs.h  conflict!
 'v'   00-0F  linux/sonypi.h  conflict!
 'v'   00-0F  media/v4l2-subdev.h conflict!
+'v'   20-27  arch/powerpc/include/uapi/asm/vas-api.hVAS API
 'v'   C0-FF  linux/meye.hconflict!
 'w'   allCERN SCI 
driver
 'y'   00-1F  packet 
based user level communications
diff --git a/arch/powerpc/include/uapi/asm/vas-api.h 
b/arch/powerpc/include/uapi/asm/vas-api.h
new file mode 100644
index 000..fe95d67
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/vas-api.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
+/*
+ * Copyright 2019 IBM Corp.
+ */
+
+#ifndef _UAPI_MISC_VAS_H
+#define _UAPI_MISC_VAS_H
+
+#include 
+
+#define VAS_MAGIC  'v'
+#define VAS_TX_WIN_OPEN_IOW(VAS_MAGIC, 0x20, struct 
vas_tx_win_open_attr)
+
+struct vas_tx_win_open_attr {
+   __u32   version;
+   __s16   vas_id; /* specific instance of vas or -1 for default */
+   __u16   reserved1;
+   __u64   flags;  /* Future use */
+   __u64   reserved2[6];
+};
+
+#endif /* _UAPI_MISC_VAS_H */
-- 
1.8.3.1





[PATCH 04/10] crypto/nx: Initialize coproc entry with kzalloc

2019-12-15 Thread Haren Myneni


coproc entry is initialized during NX probe on power9, but not on P8.
nx842_delete_coprocs() is used for both and frees receive window if it
is allocated. Getting crash for rmmod on P8 since coproc->vas.rxwin
is not initialized.

This patch replaces kmalloc with kzalloc in nx842_powernv_probe()

Signed-off-by: Haren Myneni 
---
 drivers/crypto/nx/nx-842-powernv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index c037a24..8e63326 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -922,7 +922,7 @@ static int __init nx842_powernv_probe(struct device_node 
*dn)
return -EINVAL;
}
 
-   coproc = kmalloc(sizeof(*coproc), GFP_KERNEL);
+   coproc = kzalloc(sizeof(*coproc), GFP_KERNEL);
if (!coproc)
return -ENOMEM;
 
-- 
1.8.3.1





[PATCH 05/10] crypto/nx: Organize powernv 842 code to add new GZIP compression type

2019-12-15 Thread Haren Myneni


Move common code for 842 and GZIP such as initializtion, read device
tree entries and allocation of receive and send (kernel usage) windows
to nx-common-powernv.c and keep 842 specific code in nx-842-powernv.c

Signed-off-by: Haren Myneni 
---
 drivers/crypto/nx/Makefile|   2 +-
 drivers/crypto/nx/nx-842-powernv.c| 412 +-
 drivers/crypto/nx/nx-842-powernv.h|  29 +++
 drivers/crypto/nx/nx-commom-powernv.c | 408 +
 4 files changed, 447 insertions(+), 404 deletions(-)
 create mode 100644 drivers/crypto/nx/nx-842-powernv.h
 create mode 100644 drivers/crypto/nx/nx-commom-powernv.c

diff --git a/drivers/crypto/nx/Makefile b/drivers/crypto/nx/Makefile
index 015155d..1949449 100644
--- a/drivers/crypto/nx/Makefile
+++ b/drivers/crypto/nx/Makefile
@@ -15,4 +15,4 @@ obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_PSERIES) += 
nx-compress-pseries.o nx-compres
 obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_POWERNV) += nx-compress-powernv.o 
nx-compress.o
 nx-compress-objs := nx-842.o
 nx-compress-pseries-objs := nx-842-pseries.o
-nx-compress-powernv-objs := nx-842-powernv.o
+nx-compress-powernv-objs := nx-commom-powernv.o nx-842-powernv.o
diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index 8e63326..1469ad8 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -1,32 +1,18 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 /*
- * Driver for IBM PowerNV 842 compression accelerator
+ * IBM PowerNV NX 842 compression API
  *
  * Copyright (C) 2015 Dan Streetman, IBM Corp
  */
 
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
 #include "nx-842.h"
 
 #include 
 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Dan Streetman ");
-MODULE_DESCRIPTION("842 H/W Compression driver for IBM PowerNV processors");
-MODULE_ALIAS_CRYPTO("842");
-MODULE_ALIAS_CRYPTO("842-nx");
-
-#define WORKMEM_ALIGN  (CRB_ALIGN)
-#define CSB_WAIT_MAX   (5000) /* ms */
-#define VAS_RETRIES(10)
+#include "nx-842-powernv.h"
 
 struct nx842_workmem {
/* Below fields must be properly aligned */
@@ -40,30 +26,10 @@ struct nx842_workmem {
char padding[WORKMEM_ALIGN]; /* unused, to allow alignment */
 } __packed __aligned(WORKMEM_ALIGN);
 
-struct nx842_coproc {
-   unsigned int chip_id;
-   unsigned int ct;
-   unsigned int ci;/* Coprocessor instance, used with icswx */
-   struct {
-   struct vas_window *rxwin;
-   int id;
-   } vas;
-   struct list_head list;
-};
-
-/*
- * Send the request to NX engine on the chip for the corresponding CPU
- * where the process is executing. Use with VAS function.
- */
-static DEFINE_PER_CPU(struct vas_window *, cpu_txwin);
-
-/* no cpu hotplug on powernv, so this list never changes after init */
-static LIST_HEAD(nx842_coprocs);
-static unsigned int nx842_ct;  /* used in icswx function */
-
-static int (*nx842_powernv_exec)(const unsigned char *in,
-   unsigned int inlen, unsigned char *out,
-   unsigned int *outlenp, void *workmem, int fc);
+int (*nx842_powernv_exec)(const unsigned char *in, unsigned int inlen,
+   unsigned char *out, unsigned int *outlenp,
+   void *workmem, int fc);
+DECLARE_PER_CPU(struct vas_window *, cpu_txwin);
 
 /**
  * setup_indirect_dde - Setup an indirect DDE
@@ -446,7 +412,7 @@ static int nx842_config_crb(const unsigned char *in, 
unsigned int inlen,
  *   -ETIMEDOUThardware did not complete operation in reasonable time
  *   -EINTRoperation was aborted
  */
-static int nx842_exec_icswx(const unsigned char *in, unsigned int inlen,
+int nx842_exec_icswx(const unsigned char *in, unsigned int inlen,
  unsigned char *out, unsigned int *outlenp,
  void *workmem, int fc)
 {
@@ -549,7 +515,7 @@ static int nx842_exec_icswx(const unsigned char *in, 
unsigned int inlen,
  *   -ETIMEDOUThardware did not complete operation in reasonable time
  *   -EINTRoperation was aborted
  */
-static int nx842_exec_vas(const unsigned char *in, unsigned int inlen,
+int nx842_exec_vas(const unsigned char *in, unsigned int inlen,
  unsigned char *out, unsigned int *outlenp,
  void *workmem, int fc)
 {
@@ -666,307 +632,6 @@ static int nx842_powernv_decompress(const unsigned char 
*in, unsigned int inlen,
  wmem, CCW_FC_842_DECOMP_CRC);
 }
 
-static inline void nx842_add_coprocs_list(struct nx842_coproc *coproc,
-   int chipid)
-{
-   coproc->chip_id = chipid;
-   INIT_LIST_HEAD(&coproc->list);
-   list_add(&coproc->list, &nx842_coprocs);
-}
-
-static struct vas_window *nx842_alloc_txwin(struct nx842_coproc *cop

[PATCH 06/10] crypto/NX: Make code generic to add new GZIP compression

2019-12-15 Thread Haren Myneni


Make code generic so that extend it to support new GZIP compression
type. Changed nx842 reference to nx and moved some code to new
functions. The actual functionality is not changed.

Signed-off-by: Haren Myneni 
---
 drivers/crypto/nx/nx-commom-powernv.c | 160 +-
 1 file changed, 100 insertions(+), 60 deletions(-)

diff --git a/drivers/crypto/nx/nx-commom-powernv.c 
b/drivers/crypto/nx/nx-commom-powernv.c
index 799ba28..86efa4f 100644
--- a/drivers/crypto/nx/nx-commom-powernv.c
+++ b/drivers/crypto/nx/nx-commom-powernv.c
@@ -23,9 +23,9 @@
 MODULE_ALIAS_CRYPTO("842");
 MODULE_ALIAS_CRYPTO("842-nx");
 
-struct nx842_coproc {
+struct nx_coproc {
unsigned int chip_id;
-   unsigned int ct;
+   unsigned int ct;/* Can be 842 or GZIP high/normal*/
unsigned int ci;/* Coprocessor instance, used with icswx */
struct {
struct vas_window *rxwin;
@@ -43,17 +43,23 @@ struct nx842_coproc {
 unsigned int nx842_ct; /* used in icswx function */
 
 /* no cpu hotplug on powernv, so this list never changes after init */
-static LIST_HEAD(nx842_coprocs);
+static LIST_HEAD(nx_coprocs);
 
-static inline void nx842_add_coprocs_list(struct nx842_coproc *coproc,
+/*
+ * Using same values as in skiboot or coprocessor type representing
+ * in NX workbook.
+ */
+#define NX_CT_842  (3)
+
+static inline void nx_add_coprocs_list(struct nx_coproc *coproc,
int chipid)
 {
coproc->chip_id = chipid;
INIT_LIST_HEAD(&coproc->list);
-   list_add(&coproc->list, &nx842_coprocs);
+   list_add(&coproc->list, &nx_coprocs);
 }
 
-static struct vas_window *nx842_alloc_txwin(struct nx842_coproc *coproc)
+static struct vas_window *nx_alloc_txwin(struct nx_coproc *coproc)
 {
struct vas_window *txwin = NULL;
struct vas_tx_win_attr txattr;
@@ -83,9 +89,9 @@ static struct vas_window *nx842_alloc_txwin(struct 
nx842_coproc *coproc)
  * cpu_txwin is used in copy/paste operation for each compression /
  * decompression request.
  */
-static int nx842_open_percpu_txwins(void)
+static int nx_open_percpu_txwins(void)
 {
-   struct nx842_coproc *coproc, *n;
+   struct nx_coproc *coproc, *n;
unsigned int i, chip_id;
 
for_each_possible_cpu(i) {
@@ -93,17 +99,18 @@ static int nx842_open_percpu_txwins(void)
 
chip_id = cpu_to_chip_id(i);
 
-   list_for_each_entry_safe(coproc, n, &nx842_coprocs, list) {
+   list_for_each_entry_safe(coproc, n, &nx_coprocs, list) {
/*
 * Kernel requests use only high priority FIFOs. So
 * open send windows for these FIFOs.
+* GZIP is not supported in kernel right now.
 */
 
if (coproc->ct != VAS_COP_TYPE_842_HIPRI)
continue;
 
if (coproc->chip_id == chip_id) {
-   txwin = nx842_alloc_txwin(coproc);
+   txwin = nx_alloc_txwin(coproc);
if (IS_ERR(txwin))
return PTR_ERR(txwin);
 
@@ -122,15 +129,30 @@ static int nx842_open_percpu_txwins(void)
return 0;
 }
 
+static int __init nx_set_ct(struct nx_coproc *coproc, const char *priority,
+   int high, int normal)
+{
+   if (!strcmp(priority, "High"))
+   coproc->ct = high;
+   else if (!strcmp(priority, "Normal"))
+   coproc->ct = normal;
+   else {
+   pr_err("Invalid RxFIFO priority value\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static int __init vas_cfg_coproc_info(struct device_node *dn, int chip_id,
-   int vasid, int *ct)
+   int vasid, int type, int *ct)
 {
struct vas_window *rxwin = NULL;
struct vas_rx_win_attr rxattr;
-   struct nx842_coproc *coproc;
u32 lpid, pid, tid, fifo_size;
-   u64 rx_fifo;
+   struct nx_coproc *coproc;
const char *priority;
+   u64 rx_fifo;
int ret;
 
ret = of_property_read_u64(dn, "rx-fifo-address", &rx_fifo);
@@ -173,15 +195,11 @@ static int __init vas_cfg_coproc_info(struct device_node 
*dn, int chip_id,
if (!coproc)
return -ENOMEM;
 
-   if (!strcmp(priority, "High"))
-   coproc->ct = VAS_COP_TYPE_842_HIPRI;
-   else if (!strcmp(priority, "Normal"))
-   coproc->ct = VAS_COP_TYPE_842;
-   else {
-   pr_err("Invalid RxFIFO priority value\n");
-   ret =  -EINVAL;
+   if (type == NX_CT_842)
+   ret = nx_set_ct(coproc, priority, VAS_COP_TYPE_842_HIPRI,
+   VAS_COP_TYPE_842);
+   if (ret)
goto err_out;
-  

[PATCH 07/10] crypto/nx: Enable and setup GZIP compresstion type

2019-12-15 Thread Haren Myneni


Changes to probe GZIP device-tree nodes, open RX windows and setup
GZIP compression type. No plans to provide GZIP usage in kernel right
now, but this patch enables GZIP for user space usage.

Signed-off-by: Haren Myneni 
---
 drivers/crypto/nx/nx-commom-powernv.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/nx/nx-commom-powernv.c 
b/drivers/crypto/nx/nx-commom-powernv.c
index 86efa4f..7cc736f 100644
--- a/drivers/crypto/nx/nx-commom-powernv.c
+++ b/drivers/crypto/nx/nx-commom-powernv.c
@@ -49,6 +49,7 @@ struct nx_coproc {
  * Using same values as in skiboot or coprocessor type representing
  * in NX workbook.
  */
+#defineNX_CT_GZIP  (2) /* on P9 and later */
 #define NX_CT_842  (3)
 
 static inline void nx_add_coprocs_list(struct nx_coproc *coproc,
@@ -198,6 +199,9 @@ static int __init vas_cfg_coproc_info(struct device_node 
*dn, int chip_id,
if (type == NX_CT_842)
ret = nx_set_ct(coproc, priority, VAS_COP_TYPE_842_HIPRI,
VAS_COP_TYPE_842);
+   else if (type == NX_CT_GZIP)
+   ret = nx_set_ct(coproc, priority, VAS_COP_TYPE_GZIP_HIPRI,
+   VAS_COP_TYPE_GZIP);
if (ret)
goto err_out;
 
@@ -245,12 +249,15 @@ static int __init vas_cfg_coproc_info(struct device_node 
*dn, int chip_id,
return ret;
 }
 
-static int __init nx_coproc_init(int chip_id, int ct_842)
+static int __init nx_coproc_init(int chip_id, int ct_842, int ct_gzip)
 {
int ret = 0;
 
if (opal_check_token(OPAL_NX_COPROC_INIT)) {
ret = opal_nx_coproc_init(chip_id, ct_842);
+
+   if (!ret)
+   ret = opal_nx_coproc_init(chip_id, ct_gzip);
if (ret) {
ret = opal_error_code(ret);
pr_err("Failed to initialize NX for chip(%d): %d\n",
@@ -280,8 +287,8 @@ static int __init find_nx_device_tree(struct device_node 
*dn, int chip_id,
 static int __init nx_powernv_probe_vas(struct device_node *pn)
 {
int chip_id, vasid, ret = 0;
+   int ct_842 = 0, ct_gzip = 0;
struct device_node *dn;
-   int ct_842 = 0;
 
chip_id = of_get_ibm_chip_id(pn);
if (chip_id < 0) {
@@ -298,19 +305,22 @@ static int __init nx_powernv_probe_vas(struct device_node 
*pn)
for_each_child_of_node(pn, dn) {
ret = find_nx_device_tree(dn, chip_id, vasid, NX_CT_842,
"ibm,p9-nx-842", &ct_842);
+   if (!ret)
+   ret = find_nx_device_tree(dn, chip_id, vasid,
+   NX_CT_GZIP, "ibm,p9-nx-gzip", &ct_gzip);
if (ret)
return ret;
}
 
-   if (!ct_842) {
-   pr_err("NX842 FIFO nodes are missing\n");
+   if (!ct_842 || !ct_gzip) {
+   pr_err("NX FIFO nodes are missing\n");
return -EINVAL;
}
 
/*
 * Initialize NX instance for both high and normal priority FIFOs.
 */
-   ret = nx_coproc_init(chip_id, ct_842);
+   ret = nx_coproc_init(chip_id, ct_842, ct_gzip);
 
return ret;
 }
-- 
1.8.3.1





[PATCH 08/10] crypto/NX: Add NX GZIP user space API

2019-12-15 Thread Haren Myneni


On power9, userspace can send GZIP compression requests directly to NX
once kernel establishes NX channel / window. This patch provides GZIP
engine access to user space via /dev/crypto/nx-gzip device node with
open, VAS_TX_WIN_OPEN ioctl, mmap and close operations.

Each window corresponds to file descriptor and application can open
multiple windows. After the window is opened, mmap() system call to map
the hardware address of engine's request queue into the application's
virtual address space.

Then the application can then submit one or more requests to the the
engine by using the copy/paste instructions and pasting the CRBs to
the virtual address (aka paste_address) returned by mmap().

Signed-off-by: Sukadev Bhattiprolu 
Signed-off-by: Haren Myneni 
---
 drivers/crypto/nx/Makefile|   2 +-
 drivers/crypto/nx/nx-842-powernv.h|   2 +
 drivers/crypto/nx/nx-commom-powernv.c |  21 ++-
 drivers/crypto/nx/nx-gzip-powernv.c   | 282 ++
 4 files changed, 304 insertions(+), 3 deletions(-)
 create mode 100644 drivers/crypto/nx/nx-gzip-powernv.c

diff --git a/drivers/crypto/nx/Makefile b/drivers/crypto/nx/Makefile
index 1949449..0394a62 100644
--- a/drivers/crypto/nx/Makefile
+++ b/drivers/crypto/nx/Makefile
@@ -15,4 +15,4 @@ obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_PSERIES) += 
nx-compress-pseries.o nx-compres
 obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_POWERNV) += nx-compress-powernv.o 
nx-compress.o
 nx-compress-objs := nx-842.o
 nx-compress-pseries-objs := nx-842-pseries.o
-nx-compress-powernv-objs := nx-commom-powernv.o nx-842-powernv.o
+nx-compress-powernv-objs := nx-commom-powernv.o nx-842-powernv.o 
nx-gzip-powernv.o
diff --git a/drivers/crypto/nx/nx-842-powernv.h 
b/drivers/crypto/nx/nx-842-powernv.h
index b754023..8aca108 100644
--- a/drivers/crypto/nx/nx-842-powernv.h
+++ b/drivers/crypto/nx/nx-842-powernv.h
@@ -25,5 +25,7 @@ extern int nx842_exec_vas(const unsigned char *in, unsigned 
int inlen,
 extern int (*nx842_powernv_exec)(const unsigned char *in, unsigned int inlen,
unsigned char *out, unsigned int *outlenp,
void *workmem, int fc);
+extern int nxgzip_device_create(void);
+extern void nxgzip_device_delete(void);
 
 #endif /* __NX_COMPRESS_POWERNV_H__ */
diff --git a/drivers/crypto/nx/nx-commom-powernv.c 
b/drivers/crypto/nx/nx-commom-powernv.c
index 7cc736f..2b89677 100644
--- a/drivers/crypto/nx/nx-commom-powernv.c
+++ b/drivers/crypto/nx/nx-commom-powernv.c
@@ -427,10 +427,19 @@ static __init int nx_compress_powernv_init(void)
nx842_powernv_exec = nx842_exec_icswx;
} else {
/*
+* Creat nx-gxip char device for user space API.
+* /dev/crypto/nx-gzip.
+* 842 compression is supported only in kernel.
+*/
+   ret = nxgzip_device_create();
+
+   /*
 * GZIP is not supported in kernel right now.
 * So open tx windows only for 842.
 */
-   ret = nx_open_percpu_txwins();
+   if (!ret)
+   ret = nx_open_percpu_txwins();
+
if (ret) {
nx_delete_coprocs();
return ret;
@@ -440,6 +449,7 @@ static __init int nx_compress_powernv_init(void)
}
 
ret = crypto_register_alg(&nx842_powernv_alg);
+
if (ret) {
nx_delete_coprocs();
return ret;
@@ -451,8 +461,15 @@ static __init int nx_compress_powernv_init(void)
 
 static void __exit nx_compress_powernv_exit(void)
 {
-   crypto_unregister_alg(&nx842_powernv_alg);
+   /*
+* GZIP engine is supported only power9 or later.
+* nx842_ct is used on power8 (icswx) and nx-gzip device is
+* created on power9 during init.
+*/
+   if (!nx842_ct)
+   nxgzip_device_delete();
 
+   crypto_unregister_alg(&nx842_powernv_alg);
nx_delete_coprocs();
 }
 module_exit(nx_compress_powernv_exit);
diff --git a/drivers/crypto/nx/nx-gzip-powernv.c 
b/drivers/crypto/nx/nx-gzip-powernv.c
new file mode 100644
index 000..cfacfea
--- /dev/null
+++ b/drivers/crypto/nx/nx-gzip-powernv.c
@@ -0,0 +1,282 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * IBM PowerNV NX gzip compression user space API
+ * Copyright (C) 2019 Haren Myneni, IBM Corp
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "nx-842-powernv.h"
+
+/*
+ * The driver creates the device /dev/crypto/nx-gzip that can be
+ * used as follows:
+ *
+ * fd = open("/dev/crypto/nx-gzip", O_RDWR);
+ * rc = ioctl(fd, VAS_TX_WIN_OPEN, &attr);
+ * paste_addr = mmap(NULL, PAGE_SIZE, prot, MAP_SHARED, fd, 0ULL).
+ * vas_copy(&crb, 0, 1);
+ * vas_paste(paste_addr, 0, 1);
+ * close(fd) or exit process to close window.
+ *
+ * where "vas_copy" and "vas_paste" are defined in copy-paste.h.
+ * copy/

[PATCH 09/10] powerpc/vas: Remove 'pid' in vas_tx_win_attr struct

2019-12-15 Thread Haren Myneni


When window is opened, pid reference is taken for user space
windows. Not needed for kernel windows. So remove 'pid' in
vas_tx_win_attr struct.

Signed-off-by: Haren Myneni 
---
 arch/powerpc/include/asm/vas.h| 1 -
 drivers/crypto/nx/nx-commom-powernv.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h
index 6d9e692..de6d909 100644
--- a/arch/powerpc/include/asm/vas.h
+++ b/arch/powerpc/include/asm/vas.h
@@ -86,7 +86,6 @@ struct vas_tx_win_attr {
int wcreds_max;
int lpid;
int pidr;   /* hardware PID (from SPRN_PID) */
-   int pid;/* linux process id */
int pswid;
int rsvd_txbuf_count;
int tc_mode;
diff --git a/drivers/crypto/nx/nx-commom-powernv.c 
b/drivers/crypto/nx/nx-commom-powernv.c
index 2b89677..9c21f37 100644
--- a/drivers/crypto/nx/nx-commom-powernv.c
+++ b/drivers/crypto/nx/nx-commom-powernv.c
@@ -71,7 +71,6 @@ static struct vas_window *nx_alloc_txwin(struct nx_coproc 
*coproc)
 */
vas_init_tx_win_attr(&txattr, coproc->ct);
txattr.lpid = 0;/* lpid is 0 for kernel requests */
-   txattr.pid = 0; /* pid is 0 for kernel requests */
 
/*
 * Open a VAS send window which is used to send request to NX.
-- 
1.8.3.1





[PATCH 10/10] Documentation/powerpc: VAS API

2019-12-15 Thread Haren Myneni


Power9 introduced Virtual Accelerator Switchboard (VAS) which allows
userspace to communicate with Nest Accelerator (NX) directly. But
kernel has to establish channel to NX for userspace. This document
describes user space API that application can use to establish
communication channel.

Signed-off-by: Sukadev Bhattiprolu 
Signed-off-by: Haren Myneni 
---
 Documentation/powerpc/index.rst   |   1 +
 Documentation/powerpc/vas-api.rst | 246
++
 2 files changed, 247 insertions(+)
 create mode 100644 Documentation/powerpc/vas-api.rst

diff --git a/Documentation/powerpc/index.rst
b/Documentation/powerpc/index.rst
index db7b6a8..8b5b167 100644
--- a/Documentation/powerpc/index.rst
+++ b/Documentation/powerpc/index.rst
@@ -27,6 +27,7 @@ powerpc
 syscall64-abi
 transactional_memory
 ultravisor
+vas-api
 
 .. only::  subproject and html
 
diff --git a/Documentation/powerpc/vas-api.rst
b/Documentation/powerpc/vas-api.rst
new file mode 100644
index 000..13ce4e7
--- /dev/null
+++ b/Documentation/powerpc/vas-api.rst
@@ -0,0 +1,246 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. _VAS-API:
+
+===
+Virtual Accelerator Switchboard (VAS) userspace API
+===
+
+Introduction
+
+
+Power9 processor introduced Virtual Accelerator Switchboard (VAS) which
+allows both userspace and kernel communicate to co-processor
+(hardware accelerator) referred to as the Nest Accelerator (NX). The NX
+unit comprises of one or more hardware engines or co-processor types
+such as 842 compression, GZIP compression and encryption. On power9,
+userspace applications will have access to only GZIP Compression engine
+which supports ZLIB and GZIP compression algorithms in the hardware.
+
+To communicate with NX, kernel has to establish a channel or window and
+then requests can be submitted directly without kernel involvement.
+Requests to the GZIP engine must be formatted as a co-processor Request
+Block (CRB) and these CRBs must be submitted to the NX using COPY/PASTE
+instructions to paste the CRB to hardware address that is associated
with
+the engine's request queue.
+
+The GZIP engine provides two priority levels of requests: Normal and
+High. Only Normal requests are supported from userspace right now.
+
+This document explains userspace API that is used to interact with
+kernel to setup channel / window which can be used to send compression
+requests directly to NX accelerator.
+
+
+Overview
+
+
+Application access to the GZIP engine is provided through
+/dev/crypto/nx-gzip device node implemented by the VAS/NX device
driver.
+An application must open the /dev/crypto/nx-gzip device to obtain a
file
+descriptor (fd). Then should issue VAS_TX_WIN_OPEN ioctl with this fd
to
+establish connection to the engine. It means send window is opened on
GZIP
+engine for this process. Once a connection is established, the
application
+should use the mmap() system call to map the hardware address of
engine's
+request queue into the application's virtual address space.
+
+The application can then submit one or more requests to the the engine
by
+using copy/paste instructions and pasting the CRBs to the virtual
address
+(aka paste_address) returned by mmap(). User space can close the
+established connection or send window by closing the file descriptior
+(close(fd)) or upon the process exit.
+
+Note that applications can send several requests with the same window
or
+can establish multiple windows, but one window for each file
descriptor.
+
+Following sections provide additional details and references about the
+individual steps.
+
+NX-GZIP Device Node
+===
+
+There is one /dev/crypto/nx-gzip node in the system and it provides
+access to all GZIP engines in the system. The only valid operations on
+/dev/crypto/nx-gzip are:
+
+   * open() the device for read and write.
+   * issue VAS_TX_WIN_OPEN ioctl
+   * mmap() the engine's request queue into application's virtual
+ address space (i.e. get a paste_address for the co-processor
+ engine).
+   * close the device node.
+
+Other file operations on this device node are undefined.
+
+Note that the copy and paste operations go directly to the hardware and
+do not go through this device. Refer COPY/PASTE document for more
+details.
+
+Although a system may have several instances of the NX co-processor
+engines (typically, one per P9 chip) there is just one
+/dev/crypto/nx-gzip device node in the system. When the nx-gzip device
+node is opened, Kernel opens send window on a suitable instance of NX
+accelerator. It finds CPU on which the user process is executing and
+determine the NX instance for the corresponding chip on which this CPU
+belongs.
+
+Applications may chose a specific instance of the NX co-processor using
+the vas_id field in the VAS_TX_WIN_OPEN ioctl as detailed below.
+
+A userspace libra

[Bug 205283] BUG: KASAN: global-out-of-bounds in _copy_to_iter+0x3d4/0x5a8

2019-12-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=205283

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Kernel Version|5.4-rc4 |5.5-rc1
   See Also||https://bugzilla.kernel.org
   ||/show_bug.cgi?id=205099

--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Re-tried with kernel 5.5-rc1. This is probably connected with bug #205099.

[...]
[   69.181890]
==
[   69.182220] BUG: KASAN: global-out-of-bounds in _copy_to_iter+0x3c0/0x594
[   69.182472] Write of size 4096 at addr f15ad000 by task modprobe/233

[   69.182738] CPU: 0 PID: 233 Comm: modprobe Tainted: GW
5.5.0-rc1-PowerMacG4+ #7
[   69.183061] Call Trace:
[   69.183147] [eb7138b8] [c0783b44] dump_stack+0xbc/0x118 (unreliable)
[   69.183387] [eb7138e8] [c024454c]
print_address_description.isra.0+0x3c/0x420
[   69.183652] [eb713978] [c0244b0c] __kasan_report+0x138/0x180
[   69.183858] [eb7139b8] [c024551c] check_memory_region+0x24/0x180
[   69.184084] [eb7139c8] [c02435e8] memcpy+0x48/0x74
[   69.184255] [eb7139e8] [c045b5cc] _copy_to_iter+0x3c0/0x594
[   69.184458] [eb713ad8] [c045b984] copy_page_to_iter+0xac/0x564
[   69.184675] [eb713b38] [c01c6d84] generic_file_read_iter+0x5c4/0x7c0
[   69.184914] [eb713ba8] [c025b8dc] __vfs_read+0x1b0/0x1f8
[   69.185106] [eb713cd8] [c025b9e0] vfs_read+0xbc/0x124
[   69.185287] [eb713d08] [c025ba9c] kernel_read+0x54/0x70
[   69.185480] [eb713d38] [c0266514] kernel_read_file+0x23c/0x34c
[   69.185694] [eb713de8] [c0266710] kernel_read_file_from_fd+0x54/0x74
[   69.185929] [eb713e18] [c0111b1c] sys_finit_module+0xd8/0x138
[   69.186139] [eb713f38] [c001a274] ret_from_syscall+0x0/0x34
[   69.186340] --- interrupt: c01 at 0x56af78
   LR = 0x6f8a14


[   69.186597] Memory state around the buggy address:
[   69.186766]  f15ad500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   69.187001]  f15ad580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   69.187235] >f15ad600: 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa
[   69.187466] ^
[   69.187656]  f15ad680: 00 00 00 03 fa fa fa fa 00 00 00 00 00 00 00 00
[   69.187890]  f15ad700: 00 00 00 00 00 00 04 fa fa fa fa fa 00 00 00 00
[   69.188121]
==
[   69.272710] raid6: altivecx8 gen()  2354 MB/s
[   69.329383] raid6: altivecx4 gen()  3200 MB/s
[   69.386055] raid6: altivecx2 gen()  2178 MB/s
[   69.442705] raid6: altivecx1 gen()  1975 MB/s
[   69.499549] raid6: int32x8  gen()   336 MB/s
[   69.556086] raid6: int32x8  xor()   200 MB/s
[   69.612793] raid6: int32x4  gen()   342 MB/s
[   69.669421] raid6: int32x4  xor()   224 MB/s
[   69.732733] raid6: int32x2  gen()   534 MB/s
[   69.796110] raid6: int32x2  xor()   414 MB/s
[   69.859399] raid6: int32x1  gen()   401 MB/s
[   69.922790] raid6: int32x1  xor()   310 MB/s
[   69.930418] raid6: using algorithm altivecx4 gen() 3200 MB/s
[   69.938166] raid6: using intx1 recovery algorithm
[   70.027661] xor: measuring software checksum speed
[   70.066059]8regs :   123.600 MB/sec
[   70.106036]8regs_prefetch:   122.400 MB/sec
[   70.146029]32regs:   126.000 MB/sec
[   70.186045]32regs_prefetch:   122.400 MB/sec
[   70.226030]altivec   :   738.000 MB/sec
[   70.233653] xor: using function: altivec (738.000 MB/sec)
[   70.713528] Btrfs loaded, crc32c=crc32c-generic, debug=on

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.

[Bug 205283] BUG: KASAN: global-out-of-bounds in _copy_to_iter+0x3d4/0x5a8

2019-12-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=205283

--- Comment #3 from Erhard F. (erhar...@mailbox.org) ---
Steps to reproduce:

1.) Configure G4 kernel with KASAN enabled
2.) Disable KASAN in lib/raid6/Makefile with KASAN_SANITIZE := n (to allow the
btrfs module to load)
3.) # modprobe -v btrfs
4.) # modprobe -r -v btrfs
5.) # modprobe -v btrfs

The 2nd time btrfs gets loaded I get this hit. But only once. Further attemps
to remove/load btrfs don't provoke the KASAN hit.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.

[Bug 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d

2019-12-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=205099

--- Comment #8 from Erhard F. (erhar...@mailbox.org) ---
Found out this is probably a cause for bug #205283. For doing some btrfs tests
with 5.5-rc1 kernel I needed to disable KASAN in lib/raid6/Makefile
(KASAN_SANITIZE := n) as btrfs pulls in raid6_pq.

btrfs gets modprobed seemingly ok the 1st time, but removing and reloading it
provokes bug #205283.

# modprobe -v btrfs
# modprobe -r -v btrfs
rmmod btrfs
rmmod zlib_inflate
rmmod libcrc32c
rmmod raid6_pq
rmmod zlib_deflate
rmmod lzo_decompress
rmmod lzo_compress
rmmod zstd_compress
rmmod zstd_decompress
rmmod xor
# modprobe -v btrfs
insmod
/lib/modules/5.5.0-rc1-PowerMacG4+/kernel/lib/zlib_inflate/zlib_inflate.ko 
insmod /lib/modules/5.5.0-rc1-PowerMacG4+/kernel/lib/libcrc32c.ko 
insmod /lib/modules/5.5.0-rc1-PowerMacG4+/kernel/lib/raid6/raid6_pq.ko 
insmod
/lib/modules/5.5.0-rc1-PowerMacG4+/kernel/lib/zlib_deflate/zlib_deflate.ko 
insmod /lib/modules/5.5.0-rc1-PowerMacG4+/kernel/lib/lzo/lzo_decompress.ko 
insmod /lib/modules/5.5.0-rc1-PowerMacG4+/kernel/lib/lzo/lzo_compress.ko 
insmod /lib/modules/5.5.0-rc1-PowerMacG4+/kernel/lib/zstd/zstd_compress.ko 
insmod /lib/modules/5.5.0-rc1-PowerMacG4+/kernel/lib/zstd/zstd_decompress.ko 
insmod /lib/modules/5.5.0-rc1-PowerMacG4+/kernel/crypto/xor.ko 
insmod /lib/modules/5.5.0-rc1-PowerMacG4+/kernel/fs/btrfs/btrfs.ko

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH] libbpf: Fix readelf output parsing for Fedora

2019-12-15 Thread Alexei Starovoitov
On Fri, Dec 13, 2019 at 9:02 AM Andrii Nakryiko
 wrote:
>
> On Fri, Dec 13, 2019 at 2:11 AM Thadeu Lima de Souza Cascardo
>  wrote:
> >
> > Fedora binutils has been patched to show "other info" for a symbol at the
> > end of the line. This was done in order to support unmaintained scripts
> > that would break with the extra info. [1]
> >
> > [1] 
> > https://src.fedoraproject.org/rpms/binutils/c/b8265c46f7ddae23a792ee8306fbaaeacba83bf8
> >
> > This in turn has been done to fix the build of ruby, because of checksec.
> > [2] Thanks Michael Ellerman for the pointer.
> >
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1479302
> >
> > As libbpf Makefile is not unmaintained, we can simply deal with either
> > output format, by just removing the "other info" field, as it always comes
> > inside brackets.
> >
> > Cc: Aurelien Jarno 
> > Fixes: 3464afdf11f9 (libbpf: Fix readelf output parsing on powerpc with 
> > recent binutils)
> > Reported-by: Justin Forbes 
> > Signed-off-by: Thadeu Lima de Souza Cascardo 
> > ---
>
> I was briefly playing with it and trying to make it use nm to dump
> symbols, instead of parsing more human-oriented output of readelf, but
> somehow nm doesn't output symbols with @@LIBBPF.* suffix at the end,
> so I just gave up. So I think this one is good.
>
> This should go through bpf-next tree.
>
> Acked-by: Andrii Nakryiko 

Applied. Thanks


Re: [PATCH] libbpf: Fix readelf output parsing for Fedora

2019-12-15 Thread Andrii Nakryiko
On Fri, Dec 13, 2019 at 2:11 AM Thadeu Lima de Souza Cascardo
 wrote:
>
> Fedora binutils has been patched to show "other info" for a symbol at the
> end of the line. This was done in order to support unmaintained scripts
> that would break with the extra info. [1]
>
> [1] 
> https://src.fedoraproject.org/rpms/binutils/c/b8265c46f7ddae23a792ee8306fbaaeacba83bf8
>
> This in turn has been done to fix the build of ruby, because of checksec.
> [2] Thanks Michael Ellerman for the pointer.
>
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1479302
>
> As libbpf Makefile is not unmaintained, we can simply deal with either
> output format, by just removing the "other info" field, as it always comes
> inside brackets.
>
> Cc: Aurelien Jarno 
> Fixes: 3464afdf11f9 (libbpf: Fix readelf output parsing on powerpc with 
> recent binutils)
> Reported-by: Justin Forbes 
> Signed-off-by: Thadeu Lima de Souza Cascardo 
> ---

I was briefly playing with it and trying to make it use nm to dump
symbols, instead of parsing more human-oriented output of readelf, but
somehow nm doesn't output symbols with @@LIBBPF.* suffix at the end,
so I just gave up. So I think this one is good.

This should go through bpf-next tree.

Acked-by: Andrii Nakryiko 


>  tools/lib/bpf/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> index defae23a0169..23ae06c43d08 100644
> --- a/tools/lib/bpf/Makefile
> +++ b/tools/lib/bpf/Makefile
> @@ -147,6 +147,7 @@ TAGS_PROG := $(if $(shell which etags 
> 2>/dev/null),etags,ctags)
>
>  GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN_SHARED) | \
>cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | 
> \
> +  sed 's/\[.*\]//' | \
>awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$NF}' 
> | \
>sort -u | wc -l)
>  VERSIONED_SYM_COUNT = $(shell readelf -s --wide $(OUTPUT)libbpf.so | \
> @@ -213,6 +214,7 @@ check_abi: $(OUTPUT)libbpf.so
>  "versioned in $(VERSION_SCRIPT)." >&2;  \
> readelf -s --wide $(BPF_IN_SHARED) | \
> cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' |   \
> +   sed 's/\[.*\]//' |   \
> awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$NF}'|  \
> sort -u > $(OUTPUT)libbpf_global_syms.tmp;   \
> readelf -s --wide $(OUTPUT)libbpf.so |   \
> --
> 2.24.0
>


Re: [PATCH 10/10] soc: qcom: convert to devm_platform_ioremap_resource

2019-12-15 Thread Marc Zyngier
On Sat, 14 Dec 2019 17:54:47 +
Yangtao Li  wrote:

> Use devm_platform_ioremap_resource() to simplify code.
> 
> Signed-off-by: Yangtao Li 
> ---
>  drivers/soc/qcom/llcc-qcom.c| 7 +--
>  drivers/soc/qcom/qcom-geni-se.c | 4 +---
>  drivers/soc/qcom/qcom_aoss.c| 4 +---
>  drivers/soc/qcom/qcom_gsbi.c| 5 +
>  drivers/soc/qcom/spm.c  | 4 +---
>  5 files changed, 5 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c
> index 429b5a60a1ba..99e19df76889 100644
> --- a/drivers/soc/qcom/llcc-qcom.c
> +++ b/drivers/soc/qcom/llcc-qcom.c
> @@ -387,7 +387,6 @@ static int qcom_llcc_remove(struct platform_device *pdev)
>  static struct regmap *qcom_llcc_init_mmio(struct platform_device *pdev,
>   const char *name)
>  {
> - struct resource *res;
>   void __iomem *base;
>   struct regmap_config llcc_regmap_config = {
>   .reg_bits = 32,
> @@ -396,11 +395,7 @@ static struct regmap *qcom_llcc_init_mmio(struct 
> platform_device *pdev,
>   .fast_io = true,
>   };
>  
> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
> - if (!res)
> - return ERR_PTR(-ENODEV);
> -
> - base = devm_ioremap_resource(&pdev->dev, res);
> + base = devm_platform_ioremap_resource(pdev, 0);

What guarantees do you have that entry 0 matches name?

I find these changes pointless: they don't add much to the readability
or maintainability of the code, and instead introduce creative bugs.

M.
-- 
Jazz is not dead. It just smells funny...


Re: [PATCH v2 25/27] nvdimm/ocxl: Expose SMART data via ndctl

2019-12-15 Thread Alastair D'Silva
On Tue, 2019-12-03 at 14:46 +1100, Alastair D'Silva wrote:
> From: Alastair D'Silva 
> 
> This patch retrieves proprietary formatted SMART data and makes it
> available via ndctl. A later contribution will be made to ndctl to
> parse this data.
> 
> Signed-off-by: Alastair D'Silva 

Dan,

I should ask, is there a defined format that ND_CMD_SMART should be
returning data in, or is it reasonable to have this implementation
dependent?


> ---
>  drivers/nvdimm/ocxl/scm.c  | 156
> +
>  drivers/nvdimm/ocxl/scm_internal.h |  21 
>  2 files changed, 177 insertions(+)
> 
> diff --git a/drivers/nvdimm/ocxl/scm.c b/drivers/nvdimm/ocxl/scm.c
> index 8deb7862793c..77b9e68870a3 100644
> --- a/drivers/nvdimm/ocxl/scm.c
> +++ b/drivers/nvdimm/ocxl/scm.c
> @@ -94,6 +94,157 @@ static int scm_ndctl_config_size(struct
> nd_cmd_get_config_size *command)
>   return 0;
>  }
>  
> +static int read_smart_attrib(struct scm_data *scm_data, u16 offset,
> +  struct scm_smart_attribs *attribs)
> +{
> + u64 val;
> + int rc;
> + struct scm_smart_attrib *attrib;
> + u8 attrib_id;
> +
> + rc = ocxl_global_mmio_read64(scm_data->ocxl_afu, offset,
> OCXL_LITTLE_ENDIAN,
> +  &val);
> + if (rc)
> + return rc;
> +
> + attrib_id = (val >> 56) & 0xff;
> + switch (attrib_id) {
> + case SCM_SMART_ATTR_POWER_ON_HOURS:
> + attrib = &attribs->power_on_hours;
> + break;
> +
> + case SCM_SMART_ATTR_TEMPERATURE:
> + attrib = &attribs->temperature;
> + break;
> +
> + case SCM_SMART_ATTR_LIFE_REMAINING:
> + attrib = &attribs->life_remaining;
> + break;
> +
> + default:
> + dev_warn(&scm_data->dev, "Unknown smart attrib '%d'",
> attrib_id);
> + return -ENOENT;
> + }
> +
> + attrib->id = attrib_id;
> + attrib->attribute_flags = (val >> 40) & 0x;
> + attrib->current_val = (val >> 32) & 0xff;
> + attrib->threshold_val = (val >> 24) & 0xff;
> + attrib->worst_val = (val >> 16) & 0xff;
> +
> + rc = ocxl_global_mmio_read64(scm_data->ocxl_afu, offset + 0x08,
> +  OCXL_LITTLE_ENDIAN, &val);
> + if (rc)
> + return rc;
> +
> + attrib->raw_val = val;
> +
> + return 0;
> +}
> +
> +/**
> + * scm_smart_header_parse() - Parse the first 64 bits of the SMART
> admin command response
> + * @scm_data: the SCM metadata
> + * @length: out, returns the number of bytes in the response
> (excluding the 64 bit header)
> + */
> +static int scm_smart_header_parse(struct scm_data *scm_data, u32
> *length)
> +{
> + int rc;
> + u64 val;
> +
> + u16 data_identifier;
> + u32 data_length;
> +
> + rc = ocxl_global_mmio_read64(scm_data->ocxl_afu,
> +  scm_data-
> >admin_command.data_offset,
> +  OCXL_LITTLE_ENDIAN, &val);
> + if (rc)
> + return rc;
> +
> + data_identifier = val >> 48;
> + data_length = val & 0x;
> +
> + if (data_identifier != 0x534D) {
> + dev_err(&scm_data->dev,
> + "Bad data identifier for smart data, expected
> 'SM', got '%-.*s'\n",
> + 2, (char *)&data_identifier);
> + return -EINVAL;
> + }
> +
> + *length = data_length;
> + return 0;
> +}
> +
> +static int scm_smart_update(struct scm_data *scm_data)
> +{
> + u32 length, i;
> + int rc;
> +
> + mutex_lock(&scm_data->admin_command.lock);
> +
> + rc = scm_admin_command_request(scm_data, ADMIN_COMMAND_SMART);
> + if (rc)
> + goto out;
> +
> + rc = scm_admin_command_execute(scm_data);
> + if (rc)
> + goto out;
> +
> + rc = scm_admin_command_complete_timeout(scm_data,
> ADMIN_COMMAND_SMART);
> + if (rc < 0) {
> + dev_err(&scm_data->dev, "SMART timeout\n");
> + goto out;
> + }
> +
> + rc = scm_admin_response(scm_data);
> + if (rc < 0)
> + goto out;
> + if (rc != STATUS_SUCCESS) {
> + scm_warn_status(scm_data, "Unexpected status from
> SMART", rc);
> + goto out;
> + }
> +
> + rc = scm_smart_header_parse(scm_data, &length);
> + if (rc)
> + goto out;
> +
> + length /= 0x10; // Length now contains the number of attributes
> +
> + for (i = 0; i < length; i++)
> + read_smart_attrib(scm_data,
> +   scm_data->admin_command.data_offset +
> 0x08 + i * 0x10,
> +   &scm_data->smart);
> +
> + rc = scm_admin_response_handled(scm_data);
> + if (rc)
> + goto out;
> +
> + rc = 0;
> + goto out;
> +
> +out:
> + mutex_unlock(&scm_data->admin_command.lock);
> + return rc;
> +}
> +
> +static int scm_ndctl_smart(struct scm_data *scm_data, void *buf,
> +  

Re: [PATCH V3 2/2] KVM: PPC: Implement H_SVM_INIT_ABORT hcall

2019-12-15 Thread Bharata B Rao
On Sat, Dec 14, 2019 at 06:12:08PM -0800, Sukadev Bhattiprolu wrote:
> +unsigned long kvmppc_h_svm_init_abort(struct kvm *kvm)
> +{
> + int i;
> +
> + if (!(kvm->arch.secure_guest & KVMPPC_SECURE_INIT_START))
> + return H_UNSUPPORTED;
> +
> + for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
> + struct kvm_memory_slot *memslot;
> + struct kvm_memslots *slots = __kvm_memslots(kvm, i);
> +
> + if (!slots)
> + continue;
> +
> + kvm_for_each_memslot(memslot, slots)
> + kvmppc_uvmem_drop_pages(memslot, kvm, false);
> + }

You need to hold srcu_read_lock(&kvm->srcu) here.

Regards,
Bharata.



[PATCH kernel v2 1/4] Revert "powerpc/pseries/iommu: Don't use dma_iommu_ops on secure guests"

2019-12-15 Thread Alexey Kardashevskiy
From: Ram Pai 

This reverts commit edea902c1c1efb855f77e041f9daf1abe7a9768a.

At the time the change allowed direct DMA ops for secure VMs; however
since then we switched on using SWIOTLB backed with IOMMU (direct mapping)
and to make this work, we need dma_iommu_ops which handles all cases
including TCE mapping I/O pages in the presence of an IOMMU.

Fixes: edea902c1c1e ("powerpc/pseries/iommu: Don't use dma_iommu_ops on secure 
guests")
Signed-off-by: Ram Pai 
[aik: added "revert" and "fixes:"]
Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v2
* made it a revert patch, added "fixes:"
---
 arch/powerpc/platforms/pseries/iommu.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/iommu.c 
b/arch/powerpc/platforms/pseries/iommu.c
index 6ba081dd61c9..df7db33ca93b 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "pseries.h"
 
@@ -1320,15 +1319,7 @@ void iommu_init_early_pSeries(void)
of_reconfig_notifier_register(&iommu_reconfig_nb);
register_memory_notifier(&iommu_mem_nb);
 
-   /*
-* Secure guest memory is inacessible to devices so regular DMA isn't
-* possible.
-*
-* In that case keep devices' dma_map_ops as NULL so that the generic
-* DMA code path will use SWIOTLB to bounce buffers for DMA.
-*/
-   if (!is_secure_guest())
-   set_pci_dma_ops(&dma_iommu_ops);
+   set_pci_dma_ops(&dma_iommu_ops);
 }
 
 static int __init disable_multitce(char *str)
-- 
2.17.1



[PATCH kernel v2 0/4] Enable IOMMU support for pseries Secure VMs

2019-12-15 Thread Alexey Kardashevskiy
This enables IOMMU for SVM. Instead of sharing
a H_PUT_TCE_INDIRECT page, this uses H_PUT_TCE for mapping
and H_STUFF_TCE for clearing TCEs which should bring
acceptable performance at the boot time; otherwise things
work with the same speed anyway.

Please comment. Thanks.


This is based on sha1
37d4e84f765b Linus Torvalds Merge tag 'ceph-for-5.5-rc2' of 
git://github.com/ceph/ceph-client

Please comment. Thanks.



Alexey Kardashevskiy (3):
  powerpc/pseries: Allow not having
ibm,hypertas-functions::hcall-multi-tce for DDW
  powerpc/pseries/iommu: Separate FW_FEATURE_MULTITCE to put/stuff
features
  powerpc/pseries/svm: Allow IOMMU to work in SVM

Ram Pai (1):
  Revert "powerpc/pseries/iommu: Don't use dma_iommu_ops on secure
guests"

 arch/powerpc/include/asm/firmware.h   |  6 ++-
 arch/powerpc/platforms/pseries/firmware.c | 10 +++-
 arch/powerpc/platforms/pseries/iommu.c| 65 +--
 3 files changed, 50 insertions(+), 31 deletions(-)

-- 
2.17.1



[PATCH kernel v2 2/4] powerpc/pseries: Allow not having ibm, hypertas-functions::hcall-multi-tce for DDW

2019-12-15 Thread Alexey Kardashevskiy
By default a pseries guest supports a H_PUT_TCE hypercall which maps
a single IOMMU page in a DMA window. Additionally the hypervisor may
support H_PUT_TCE_INDIRECT/H_STUFF_TCE which update multiple TCEs at once;
this is advertised via the device tree /rtas/ibm,hypertas-functions
property which Linux converts to FW_FEATURE_MULTITCE.

FW_FEATURE_MULTITCE is checked when dma_iommu_ops is used; however
the code managing the huge DMA window (DDW) ignores it and calls
H_PUT_TCE_INDIRECT even if it is explicitly disabled via
the "multitce=off" kernel command line parameter.

This adds FW_FEATURE_MULTITCE checking to the DDW code path.

This changes tce_build_pSeriesLP to take liobn and page size as
the huge window does not have iommu_table descriptor which usually
the place to store these numbers.

Fixes: 4e8b0cf46b25 ("powerpc/pseries: Add support for dynamic dma windows")
Signed-off-by: Alexey Kardashevskiy 
---

I've put "Fixes" which is from 2011-02-10 but probably should remove it,
or otherwise all these "stable backport branch" scripts will react on
"Fixes" and try pulling this back and we do not really want this as
this patch won't help anyone with anything useful.

---
Changes:
v2
* added "fixes"
---
 arch/powerpc/platforms/pseries/iommu.c | 44 ++
 1 file changed, 30 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/iommu.c 
b/arch/powerpc/platforms/pseries/iommu.c
index df7db33ca93b..f6e9b87c82fc 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -132,10 +132,10 @@ static unsigned long tce_get_pseries(struct iommu_table 
*tbl, long index)
return be64_to_cpu(*tcep);
 }
 
-static void tce_free_pSeriesLP(struct iommu_table*, long, long);
+static void tce_free_pSeriesLP(unsigned long liobn, long, long);
 static void tce_freemulti_pSeriesLP(struct iommu_table*, long, long);
 
-static int tce_build_pSeriesLP(struct iommu_table *tbl, long tcenum,
+static int tce_build_pSeriesLP(unsigned long liobn, long tcenum, long tceshift,
long npages, unsigned long uaddr,
enum dma_data_direction direction,
unsigned long attrs)
@@ -146,25 +146,25 @@ static int tce_build_pSeriesLP(struct iommu_table *tbl, 
long tcenum,
int ret = 0;
long tcenum_start = tcenum, npages_start = npages;
 
-   rpn = __pa(uaddr) >> TCE_SHIFT;
+   rpn = __pa(uaddr) >> tceshift;
proto_tce = TCE_PCI_READ;
if (direction != DMA_TO_DEVICE)
proto_tce |= TCE_PCI_WRITE;
 
while (npages--) {
-   tce = proto_tce | (rpn & TCE_RPN_MASK) << TCE_RPN_SHIFT;
-   rc = plpar_tce_put((u64)tbl->it_index, (u64)tcenum << 12, tce);
+   tce = proto_tce | (rpn & TCE_RPN_MASK) << tceshift;
+   rc = plpar_tce_put((u64)liobn, (u64)tcenum << tceshift, tce);
 
if (unlikely(rc == H_NOT_ENOUGH_RESOURCES)) {
ret = (int)rc;
-   tce_free_pSeriesLP(tbl, tcenum_start,
+   tce_free_pSeriesLP(liobn, tcenum_start,
   (npages_start - (npages + 1)));
break;
}
 
if (rc && printk_ratelimit()) {
printk("tce_build_pSeriesLP: plpar_tce_put failed. 
rc=%lld\n", rc);
-   printk("\tindex   = 0x%llx\n", (u64)tbl->it_index);
+   printk("\tindex   = 0x%llx\n", (u64)liobn);
printk("\ttcenum  = 0x%llx\n", (u64)tcenum);
printk("\ttce val = 0x%llx\n", tce );
dump_stack();
@@ -193,7 +193,8 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table 
*tbl, long tcenum,
unsigned long flags;
 
if ((npages == 1) || !firmware_has_feature(FW_FEATURE_MULTITCE)) {
-   return tce_build_pSeriesLP(tbl, tcenum, npages, uaddr,
+   return tce_build_pSeriesLP(tbl->it_index, tcenum,
+  tbl->it_page_shift, npages, uaddr,
   direction, attrs);
}
 
@@ -209,8 +210,9 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table 
*tbl, long tcenum,
/* If allocation fails, fall back to the loop implementation */
if (!tcep) {
local_irq_restore(flags);
-   return tce_build_pSeriesLP(tbl, tcenum, npages, uaddr,
-   direction, attrs);
+   return tce_build_pSeriesLP(tbl->it_index, tcenum,
+   tbl->it_page_shift,
+   npages, uaddr, direction, attrs);
}
__this_cpu_write(tce_page, tcep);
}
@@ -261,16 +263,16 @@ static int tce_buildmulti_pSeriesLP(struct iommu

[PATCH kernel v2 3/4] powerpc/pseries/iommu: Separate FW_FEATURE_MULTITCE to put/stuff features

2019-12-15 Thread Alexey Kardashevskiy
H_PUT_TCE_INDIRECT allows packing up to 512 TCE updates into a single
hypercall; H_STUFF_TCE can clear lots in a single hypercall too.

However, unlike H_STUFF_TCE (which writes the same TCE to all entries),
H_PUT_TCE_INDIRECT uses a 4K page with new TCEs. In a secure VM
environment this means sharing a secure VM page with a hypervisor which
we would rather avoid.

This splits the FW_FEATURE_MULTITCE feature into FW_FEATURE_PUT_TCE_IND
and FW_FEATURE_STUFF_TCE. "hcall-multi-tce" in
the "/rtas/ibm,hypertas-functions" device tree property sets both;
the "multitce=off" kernel command line parameter disables both.

This should not cause behavioural change.

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v2
* instead of checking for secure VM here and there, this adds a new
FW feature
* moved SVM enablement to a separate patch
---
 arch/powerpc/include/asm/firmware.h   |  6 --
 arch/powerpc/platforms/pseries/firmware.c |  3 ++-
 arch/powerpc/platforms/pseries/iommu.c| 12 +++-
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/include/asm/firmware.h 
b/arch/powerpc/include/asm/firmware.h
index b3e214a97f3a..ca33f4ef6cb4 100644
--- a/arch/powerpc/include/asm/firmware.h
+++ b/arch/powerpc/include/asm/firmware.h
@@ -33,7 +33,7 @@
 #define FW_FEATURE_LLANASM_CONST(0x0001)
 #define FW_FEATURE_BULK_REMOVE ASM_CONST(0x0002)
 #define FW_FEATURE_XDABR   ASM_CONST(0x0004)
-#define FW_FEATURE_MULTITCEASM_CONST(0x0008)
+#define FW_FEATURE_PUT_TCE_IND ASM_CONST(0x0008)
 #define FW_FEATURE_SPLPAR  ASM_CONST(0x0010)
 #define FW_FEATURE_LPARASM_CONST(0x0040)
 #define FW_FEATURE_PS3_LV1 ASM_CONST(0x0080)
@@ -51,6 +51,7 @@
 #define FW_FEATURE_BLOCK_REMOVE ASM_CONST(0x0010)
 #define FW_FEATURE_PAPR_SCMASM_CONST(0x0020)
 #define FW_FEATURE_ULTRAVISOR  ASM_CONST(0x0040)
+#define FW_FEATURE_STUFF_TCE   ASM_CONST(0x0080)
 
 #ifndef __ASSEMBLY__
 
@@ -63,7 +64,8 @@ enum {
FW_FEATURE_MIGRATE | FW_FEATURE_PERFMON | FW_FEATURE_CRQ |
FW_FEATURE_VIO | FW_FEATURE_RDMA | FW_FEATURE_LLAN |
FW_FEATURE_BULK_REMOVE | FW_FEATURE_XDABR |
-   FW_FEATURE_MULTITCE | FW_FEATURE_SPLPAR | FW_FEATURE_LPAR |
+   FW_FEATURE_PUT_TCE_IND | FW_FEATURE_STUFF_TCE |
+   FW_FEATURE_SPLPAR | FW_FEATURE_LPAR |
FW_FEATURE_CMO | FW_FEATURE_VPHN | FW_FEATURE_XCMO |
FW_FEATURE_SET_MODE | FW_FEATURE_BEST_ENERGY |
FW_FEATURE_TYPE1_AFFINITY | FW_FEATURE_PRRN |
diff --git a/arch/powerpc/platforms/pseries/firmware.c 
b/arch/powerpc/platforms/pseries/firmware.c
index d4a8f1702417..d3acff23f2e3 100644
--- a/arch/powerpc/platforms/pseries/firmware.c
+++ b/arch/powerpc/platforms/pseries/firmware.c
@@ -55,7 +55,8 @@ hypertas_fw_features_table[] = {
{FW_FEATURE_LLAN,   "hcall-lLAN"},
{FW_FEATURE_BULK_REMOVE,"hcall-bulk"},
{FW_FEATURE_XDABR,  "hcall-xdabr"},
-   {FW_FEATURE_MULTITCE,   "hcall-multi-tce"},
+   {FW_FEATURE_PUT_TCE_IND | FW_FEATURE_STUFF_TCE,
+   "hcall-multi-tce"},
{FW_FEATURE_SPLPAR, "hcall-splpar"},
{FW_FEATURE_VPHN,   "hcall-vphn"},
{FW_FEATURE_SET_MODE,   "hcall-set-mode"},
diff --git a/arch/powerpc/platforms/pseries/iommu.c 
b/arch/powerpc/platforms/pseries/iommu.c
index f6e9b87c82fc..07b91938c3cc 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -192,7 +192,7 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table 
*tbl, long tcenum,
int ret = 0;
unsigned long flags;
 
-   if ((npages == 1) || !firmware_has_feature(FW_FEATURE_MULTITCE)) {
+   if ((npages == 1) || !firmware_has_feature(FW_FEATURE_PUT_TCE_IND)) {
return tce_build_pSeriesLP(tbl->it_index, tcenum,
   tbl->it_page_shift, npages, uaddr,
   direction, attrs);
@@ -286,7 +286,7 @@ static void tce_freemulti_pSeriesLP(struct iommu_table 
*tbl, long tcenum, long n
 {
u64 rc;
 
-   if (!firmware_has_feature(FW_FEATURE_MULTITCE))
+   if (!firmware_has_feature(FW_FEATURE_STUFF_TCE))
return tce_free_pSeriesLP(tbl->it_index, tcenum, npages);
 
rc = plpar_tce_stuff((u64)tbl->it_index, (u64)tcenum << 12, 0, npages);
@@ -402,7 +402,7 @@ static int tce_setrange_multi_pSeriesLP(unsigned long 
start_pfn,
u64 rc = 0;
long l, limit;
 
-   if (!firmware_has_feature(FW_FEATURE_MULTITCE)) {
+   if (!firmware_has_feature(FW_FEATURE_PUT_TCE_IND)) {
unsigned long tceshift = be32_to_cpu(maprange->tce_shift);
unsigned long dmastart 

[PATCH kernel v2 4/4] powerpc/pseries/svm: Allow IOMMU to work in SVM

2019-12-15 Thread Alexey Kardashevskiy
H_PUT_TCE_INDIRECT uses a shared page to send up to 512 TCE to
a hypervisor in a single hypercall. This does not work for secure VMs
as the page needs to be shared or the VM should use H_PUT_TCE instead.

This disables H_PUT_TCE_INDIRECT by clearing the FW_FEATURE_PUT_TCE_IND
feature bit so SVMs will map TCEs using H_PUT_TCE.

This is not a part of init_svm() as it is called too late after FW
patching is done and may result in a warning like this:

[3.727716] Firmware features changed after feature patching!
[3.727965] WARNING: CPU: 0 PID: 1 at 
(...)arch/powerpc/lib/feature-fixups.c:466 check_features+0xa4/0xc0

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v2
* new in the patchset
---
 arch/powerpc/platforms/pseries/firmware.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/powerpc/platforms/pseries/firmware.c 
b/arch/powerpc/platforms/pseries/firmware.c
index d3acff23f2e3..3e49cc23a97a 100644
--- a/arch/powerpc/platforms/pseries/firmware.c
+++ b/arch/powerpc/platforms/pseries/firmware.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "pseries.h"
 
@@ -101,6 +102,12 @@ static void __init fw_hypertas_feature_init(const char 
*hypertas,
}
}
 
+   if (is_secure_guest() &&
+   (powerpc_firmware_features & FW_FEATURE_PUT_TCE_IND)) {
+   powerpc_firmware_features &= ~FW_FEATURE_PUT_TCE_IND;
+   pr_debug("SVM: disabling PUT_TCE_IND firmware feature\n");
+   }
+
pr_debug(" <- fw_hypertas_feature_init()\n");
 }
 
-- 
2.17.1



Re: [PATCH V11] mm/debug: Add tests validating architecture page table helpers

2019-12-15 Thread Anshuman Khandual



On 12/03/2019 02:48 PM, Anshuman Khandual wrote:
> This adds tests which will validate architecture page table helpers and
> other accessors in their compliance with expected generic MM semantics.
> This will help various architectures in validating changes to existing
> page table helpers or addition of new ones.
> 
> This test covers basic page table entry transformations including but not
> limited to old, young, dirty, clean, write, write protect etc at various
> level along with populating intermediate entries with next page table page
> and validating them.
> 
> Test page table pages are allocated from system memory with required size
> and alignments. The mapped pfns at page table levels are derived from a
> real pfn representing a valid kernel text symbol. This test gets called
> right after page_alloc_init_late().
> 
> This gets build and run when CONFIG_DEBUG_VM_PGTABLE is selected along with
> CONFIG_VM_DEBUG. Architectures willing to subscribe this test also need to
> select CONFIG_ARCH_HAS_DEBUG_VM_PGTABLE which for now is limited to x86 and
> arm64. Going forward, other architectures too can enable this after fixing
> build or runtime problems (if any) with their page table helpers.
> 
> Folks interested in making sure that a given platform's page table helpers
> conform to expected generic MM semantics should enable the above config
> which will just trigger this test during boot. Any non conformity here will
> be reported as an warning which would need to be fixed. This test will help
> catch any changes to the agreed upon semantics expected from generic MM and
> enable platforms to accommodate it thereafter.

Any updates on this ?


Re: [PATCH] powerpc: Add barrier_nospec to raw_copy_in_user()

2019-12-15 Thread Michal Suchánek
On Thu, Sep 19, 2019 at 12:04:27AM +1000, Michael Ellerman wrote:
> Michal Suchánek  writes:
> > On Wed,  6 Mar 2019 12:10:38 +1100
> > Suraj Jitindar Singh  wrote:
> >
> >> Commit ddf35cf3764b ("powerpc: Use barrier_nospec in copy_from_user()")
> >> Added barrier_nospec before loading from user-controller pointers.
> >> The intention was to order the load from the potentially user-controlled
> >> pointer vs a previous branch based on an access_ok() check or similar.
> >> 
> >> In order to achieve the same result, add a barrier_nospec to the
> >> raw_copy_in_user() function before loading from such a user-controlled
> >> pointer.
> >> 
> >> Signed-off-by: Suraj Jitindar Singh 
> >> ---
> >>  arch/powerpc/include/asm/uaccess.h | 1 +
> >>  1 file changed, 1 insertion(+)
> >> 
> >> diff --git a/arch/powerpc/include/asm/uaccess.h 
> >> b/arch/powerpc/include/asm/uaccess.h
> >> index e3a731793ea2..bb615592d5bb 100644
> >> --- a/arch/powerpc/include/asm/uaccess.h
> >> +++ b/arch/powerpc/include/asm/uaccess.h
> >> @@ -306,6 +306,7 @@ extern unsigned long __copy_tofrom_user(void __user 
> >> *to,
> >>  static inline unsigned long
> >>  raw_copy_in_user(void __user *to, const void __user *from, unsigned long 
> >> n)
> >>  {
> >> +  barrier_nospec();
> >>return __copy_tofrom_user(to, from, n);
> >>  }
> >>  #endif /* __powerpc64__ */
> >
> > Hello,
> >
> > AFAICT this is not needed. The data cannot be used in the kernel without
> > subsequent copy_from_user which already has the nospec barrier.
> 
> Suraj did talk to me about this before sending the patch. My memory is
> that he came up with a scenario where it was at least theoretically
> useful, but he didn't mention that in the change log. He was working on
> nested KVM at the time.
> 
> I've now forgotten, and he's moved on to other things so probably won't
> remember either, if he's even checking his mail :/

In absence of any argument for the code and absence of the same code on
other architectures I would say you were just confused when merging
this. The code is confusing after all.

Thanks

Michal


Re: [PATCH v5 0/5] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs)

2019-12-15 Thread Bhupesh Sharma
Hi Boris,

On Sat, Dec 14, 2019 at 5:57 PM Borislav Petkov  wrote:
>
> On Fri, Nov 29, 2019 at 01:53:36AM +0530, Bhupesh Sharma wrote:
> > Bhupesh Sharma (5):
> >   crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo
> >   arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
> >   Documentation/arm64: Fix a simple typo in memory.rst
> >   Documentation/vmcoreinfo: Add documentation for 'MAX_PHYSMEM_BITS'
> >   Documentation/vmcoreinfo: Add documentation for 'TCR_EL1.T1SZ'
>
> why are those last two separate patches and not part of the patches
> which export the respective variable/define?

I remember there was a suggestion during the review of an earlier
version to keep them as a separate patch(es) so that the documentation
text is easier to review, but I have no strong preference towards the
same.

I can merge the documentation patches with the respective patches
(which export the variables/defines to vmcoreinfo) in v6, unless other
maintainers have an objections towards the same.

Thanks,
Bhupesh