* [PATCH v5,4/4] drivers: uio: new driver for fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-17 7:16 UTC (permalink / raw)
To: gregkh, linux-kernel, robh, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200417071616.44598-1-wenhu.wang@vivo.com>
A driver for freescale 85xx platforms to access the Cache-Sram form
user level. This is extremely helpful for some user-space applications
that require high performance memory accesses.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
---
Changes since v1:
* Addressed comments from Greg K-H
* Moved kfree(info->name) into uio_info_free_internal()
Changes since v2:
* Addressed comments from Greg, Scott and Christophe
* Use "uiomem->internal_addr" as if condition for sram memory free,
and memset the uiomem entry
* of_match_table modified to be apart from HW info which belong to
the HW level driver fsl_85xx_cache_sram to match
* Use roundup_pow_of_two for align calc
* Remove useless clear block of uiomem entries.
* Use UIO_INFO_VER micro for info->version, and define it as
"devicetree,pseudo", meaning this is pseudo device and probed from
device tree configuration
Changes since v3:
* Addressed comments from Christophe(use devm_xxx memory alloc interfaces)
Changes since v4:
* Use module_param_string for of_match_table, no binding to devicetree
---
drivers/uio/Kconfig | 9 ++
drivers/uio/Makefile | 1 +
drivers/uio/uio_fsl_85xx_cache_sram.c | 154 ++++++++++++++++++++++++++
3 files changed, 164 insertions(+)
create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 202ee81cfc2b..9c3b47461b71 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -105,6 +105,15 @@ config UIO_NETX
To compile this driver as a module, choose M here; the module
will be called uio_netx.
+config UIO_FSL_85XX_CACHE_SRAM
+ tristate "Freescale 85xx Cache-Sram driver"
+ depends on FSL_SOC_BOOKE && PPC32
+ select FSL_85XX_CACHE_SRAM
+ help
+ Generic driver for accessing the Cache-Sram form user level. This
+ is extremely helpful for some user-space applications that require
+ high performance memory accesses.
+
config UIO_FSL_ELBC_GPCM
tristate "eLBC/GPCM driver"
depends on FSL_LBC
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index c285dd2a4539..be2056cffc21 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -10,4 +10,5 @@ obj-$(CONFIG_UIO_NETX) += uio_netx.o
obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
obj-$(CONFIG_UIO_MF624) += uio_mf624.o
obj-$(CONFIG_UIO_FSL_ELBC_GPCM) += uio_fsl_elbc_gpcm.o
+obj-$(CONFIG_UIO_FSL_85XX_CACHE_SRAM) += uio_fsl_85xx_cache_sram.o
obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o
diff --git a/drivers/uio/uio_fsl_85xx_cache_sram.c b/drivers/uio/uio_fsl_85xx_cache_sram.c
new file mode 100644
index 000000000000..4db3648629b3
--- /dev/null
+++ b/drivers/uio/uio_fsl_85xx_cache_sram.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Vivo Communication Technology Co. Ltd.
+ * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.com>
+ * All rights reserved.
+ */
+
+#include <linux/platform_device.h>
+#include <linux/uio_driver.h>
+#include <linux/stringify.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <asm/fsl_85xx_cache_sram.h>
+
+#define DRIVER_NAME "uio_fsl_85xx_cache_sram"
+#define UIO_INFO_VER "devicetree,pseudo"
+#define UIO_NAME "uio_cache_sram"
+
+static void uio_info_free_internal(struct uio_info *info)
+{
+ int i;
+
+ for (i = 0; i < MAX_UIO_MAPS; i++) {
+ struct uio_mem *uiomem = &info->mem[i];
+
+ if (uiomem->internal_addr) {
+ mpc85xx_cache_sram_free(uiomem->internal_addr);
+ memset(uiomem, 0, sizeof(*uiomem));
+ }
+ }
+}
+
+static int uio_fsl_85xx_cache_sram_probe(struct platform_device *pdev)
+{
+ struct device_node *parent = pdev->dev.of_node;
+ struct device_node *node = NULL;
+ struct uio_info *info;
+ struct uio_mem *uiomem;
+ const char *dt_name;
+ u32 mem_size;
+ int ret;
+
+ /* alloc uio_info for one device */
+ info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ /* get optional uio name */
+ if (of_property_read_string(parent, "uio_name", &dt_name))
+ dt_name = UIO_NAME;
+
+ info->name = devm_kstrdup(&pdev->dev, dt_name, GFP_KERNEL);
+ if (!info->name)
+ return -ENOMEM;
+
+ uiomem = info->mem;
+ for_each_child_of_node(parent, node) {
+ void *virt;
+ phys_addr_t phys;
+
+ ret = of_property_read_u32(node, "cache-mem-size", &mem_size);
+ if (ret) {
+ ret = -EINVAL;
+ goto err_out;
+ }
+
+ if (mem_size == 0) {
+ dev_err(&pdev->dev, "error cache-mem-size should not be 0\n");
+ ret = -EINVAL;
+ goto err_out;
+ }
+
+ virt = mpc85xx_cache_sram_alloc(mem_size, &phys,
+ roundup_pow_of_two(mem_size));
+ if (!virt) {
+ /* mpc85xx_cache_sram_alloc to define the real cause */
+ ret = -ENOMEM;
+ goto err_out;
+ }
+
+ uiomem->memtype = UIO_MEM_PHYS;
+ uiomem->addr = phys;
+ uiomem->size = mem_size;
+ uiomem->name = kstrdup(node->name, GFP_KERNEL);
+ uiomem->internal_addr = virt;
+ uiomem++;
+
+ if (uiomem >= &info->mem[MAX_UIO_MAPS]) {
+ dev_warn(&pdev->dev, "more than %d uio-maps for device.\n",
+ MAX_UIO_MAPS);
+ break;
+ }
+ }
+
+ if (uiomem == info->mem) {
+ dev_err(&pdev->dev, "error no valid uio-map configuration found\n");
+ return -EINVAL;
+ }
+
+ info->version = UIO_INFO_VER;
+
+ /* register uio device */
+ if (uio_register_device(&pdev->dev, info)) {
+ dev_err(&pdev->dev, "error uio,cache-sram registration failed\n");
+ ret = -ENODEV;
+ goto err_out;
+ }
+
+ platform_set_drvdata(pdev, info);
+
+ return 0;
+err_out:
+ uio_info_free_internal(info);
+ return ret;
+}
+
+static int uio_fsl_85xx_cache_sram_remove(struct platform_device *pdev)
+{
+ struct uio_info *info = platform_get_drvdata(pdev);
+
+ uio_unregister_device(info);
+
+ uio_info_free_internal(info);
+
+ return 0;
+}
+
+#ifdef CONFIG_OF
+static struct of_device_id uio_fsl_85xx_cache_sram_of_match[] = {
+ { /* This is filled with module_parm */ },
+ { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, uio_fsl_85xx_cache_sram_of_match);
+
+module_param_string(of_id, uio_fsl_85xx_cache_sram_of_match[0].compatible,
+ sizeof(uio_fsl_85xx_cache_sram_of_match[0].compatible), 0);
+MODULE_PARM_DESC(of_id, "platform device id to be handled by cache-sram-uio");
+#endif
+
+static struct platform_driver uio_fsl_85xx_cache_sram = {
+ .probe = uio_fsl_85xx_cache_sram_probe,
+ .remove = uio_fsl_85xx_cache_sram_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ .of_match_table = of_match_ptr(uio_fsl_85xx_cache_sram_of_match),
+ },
+};
+
+module_platform_driver(uio_fsl_85xx_cache_sram);
+
+MODULE_AUTHOR("Wang Wenhu <wenhu.wang@vivo.com>");
+MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver");
+MODULE_ALIAS("platform:" DRIVER_NAME);
+MODULE_LICENSE("GPL v2");
--
2.17.1
^ permalink raw reply related
* [PATCH v5,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-17 7:16 UTC (permalink / raw)
To: gregkh, linux-kernel, robh, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
This series add a new uio driver for freescale 85xx platforms to
access the Cache-Sram form user level. This is extremely helpful
for the user-space applications that require high performance memory
accesses.
It fixes the compile errors and warning of the hardware level drivers
and implements the uio driver in uio_fsl_85xx_cache_sram.c.
Changes since v1:
* Addressed comments from Greg K-H
* Moved kfree(info->name) into uio_info_free_internal()
Changes since v2:
* Drop the patch that modifies Kconfigs of arch/powerpc/platforms
and modified the sequence of patches:
01:dropped, 02->03, 03->02, 04->01, 05->04
* Addressed comments from Greg, Scott and Christophe
* Use "uiomem->internal_addr" as if condition for sram memory free,
and memset the uiomem entry
* Modified of_match_table make the driver apart from Cache-Sram HW info
which belong to the HW level driver fsl_85xx_cache_sram to match
* Use roundup_pow_of_two for align calc
* Remove useless clear block of uiomem entries.
* Use UIO_INFO_VER micro for info->version, and define it as
"devicetree,pseudo", meaning this is pseudo device and probed from
device tree configuration
* Select FSL_85XX_CACHE_SRAM rather than depends on it
Changes since v3:
* Addressed comments from Christophe(use devm_xxx memory alloc interfaces)
Changes since v4:
* Use module_param_string for of_match_table, no binding to devicetree
Wang Wenhu (4):
powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr
powerpc: sysdev: fix compile error for fsl_85xx_cache_sram
powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram
drivers: uio: new driver for fsl_85xx_cache_sram
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +-
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
drivers/uio/Kconfig | 9 ++
drivers/uio/Makefile | 1 +
drivers/uio/uio_fsl_85xx_cache_sram.c | 154 ++++++++++++++++++++++
5 files changed, 167 insertions(+), 1 deletion(-)
create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
--
2.17.1
^ permalink raw reply
* [PATCH v5, 1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr
From: Wang Wenhu @ 2020-04-17 7:16 UTC (permalink / raw)
To: gregkh, linux-kernel, robh, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200417071616.44598-1-wenhu.wang@vivo.com>
Include "linux/of_address.h" to fix the compile error for
mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c.
CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’:
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error: implicit declaration of function ‘of_iomap’; did you mean ‘pci_iomap’? [-Werror=implicit-function-declaration]
l2ctlr = of_iomap(dev->dev.of_node, 0);
^~~~~~~~
pci_iomap
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:9: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
l2ctlr = of_iomap(dev->dev.of_node, 0);
^
cc1: all warnings being treated as errors
scripts/Makefile.build:267: recipe for target 'arch/powerpc/sysdev/fsl_85xx_l2ctlr.o' failed
make[2]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
---
Changes since v1:
* None
Changes since v2:
* None
Changes since v3:
* None
Changes since v4:
* None
---
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
index 2d0af0c517bb..7533572492f0 100644
--- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
+++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
@@ -10,6 +10,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of_platform.h>
+#include <linux/of_address.h>
#include <asm/io.h>
#include "fsl_85xx_cache_ctlr.h"
--
2.17.1
^ permalink raw reply related
* [PATCH v5, 2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-17 7:16 UTC (permalink / raw)
To: gregkh, linux-kernel, robh, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200417071616.44598-1-wenhu.wang@vivo.com>
Include linux/io.h into fsl_85xx_cache_sram.c to fix the
implicit-declaration compile error when building Cache-Sram.
arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’:
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’? [-Werror=implicit-function-declaration]
cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
^~~~~~~~~~~~~~~~
bitmap_complement
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
^
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration of function ‘iounmap’; did you mean ‘roundup’? [-Werror=implicit-function-declaration]
iounmap(cache_sram->base_virt);
^~~~~~~
roundup
cc1: all warnings being treated as errors
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
---
Changes since v1:
* None
Changes since v2:
* None
Changes since v3:
* None
Changes since v4:
* None
---
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index f6c665dac725..be3aef4229d7 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -17,6 +17,7 @@
#include <linux/of_platform.h>
#include <asm/pgtable.h>
#include <asm/fsl_85xx_cache_sram.h>
+#include <linux/io.h>
#include "fsl_85xx_cache_ctlr.h"
--
2.17.1
^ permalink raw reply related
* [PATCH v5, 3/4] powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-17 7:16 UTC (permalink / raw)
To: gregkh, linux-kernel, robh, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200417071616.44598-1-wenhu.wang@vivo.com>
Function instantiate_cache_sram should not be linked into the init
section for its caller mpc85xx_l2ctlr_of_probe is none-__init.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
Warning information:
MODPOST vmlinux.o
WARNING: modpost: vmlinux.o(.text+0x1e540): Section mismatch in reference from the function mpc85xx_l2ctlr_of_probe() to the function .init.text:instantiate_cache_sram()
The function mpc85xx_l2ctlr_of_probe() references
the function __init instantiate_cache_sram().
This is often because mpc85xx_l2ctlr_of_probe lacks a __init
annotation or the annotation of instantiate_cache_sram is wrong.
---
Changes since v1:
* None
Changes since v2:
* None
Changes since v3:
* None
Changes since v4:
* None
---
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index be3aef4229d7..3de5ac8382c0 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -68,7 +68,7 @@ void mpc85xx_cache_sram_free(void *ptr)
}
EXPORT_SYMBOL(mpc85xx_cache_sram_free);
-int __init instantiate_cache_sram(struct platform_device *dev,
+int instantiate_cache_sram(struct platform_device *dev,
struct sram_parameters sram_params)
{
int ret = 0;
--
2.17.1
^ permalink raw reply related
* Fix sysfs pci bus rescan on PowerNV (and other things)
From: Oliver O'Halloran @ 2020-04-17 7:35 UTC (permalink / raw)
To: linuxppc-dev
This series is based on top of my previously posted series which reworks
how devices are added to their IOMMU groups. The two series are largely
orthogonal to each other, but they both touch pnv_pci_ioda_dma_dev_setup()
so there's a minor merge conflict if they aren't applied together. I can
fix that if people think it's important, but applying them together is
probably easisest for everyone.
Base series: https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=168715
With that out of the way, what the bulk of the changes in here are in 2/4
which moves the point where we do the HW configuration to allow a bus to be
used. Currently it's done when we setup the parent bridge for that bus and
we're moving it to be done when we add the first device to that bus.
For an example of why this change is necssary this is what happens on the
current linux-next master. This has one extra patch applied to print an
error when pci_enable_device() is blocked by the platform since it helps
highlight the issue:
/sys/devices/pci0022:00/0022:00:00.0 # echo 1 > 0022\:01\:00.0/remove
e1000e 0022:01:00.0 enP34p1s0: removed PHC
e1000e 0022:01:00.0 enP34p1s0: NIC Link is Down
pci 0022:01:00.0: Removing from iommu group 11
At this point the bus 0022:01 is empty.
/sys/devices/pci0022:00/0022:00:00.0 # echo 1 > rescan
pci 0022:01:00.0: [8086:10d3] type 00 class 0x020000
pci 0022:01:00.0: reg 0x10: [mem 0x3fe9000c0000-0x3fe9000dffff]
pci 0022:01:00.0: reg 0x14: [mem 0x3fe900000000-0x3fe90007ffff]
pci 0022:01:00.0: reg 0x18: [io 0x0000-0x001f]
pci 0022:01:00.0: reg 0x1c: [mem 0x3fe9000e0000-0x3fe9000e3fff]
pci 0022:01:00.0: reg 0x30: [mem 0x00000000-0x0003ffff pref]
pci 0022:01:00.0: BAR3 [mem size 0x00004000]: requesting alignment to 0x10000
pci 0022:01:00.0: PME# supported from D0 D3hot D3cold
pci 0022:00:00.0: BAR 13: no space for [io size 0x1000]
pci 0022:00:00.0: BAR 13: failed to assign [io size 0x1000]
pci 0022:01:00.0: BAR 1: assigned [mem 0x3fe900000000-0x3fe90007ffff]
pci 0022:01:00.0: BAR 6: assigned [mem 0x3fe900080000-0x3fe9000bffff pref]
pci 0022:01:00.0: BAR 0: assigned [mem 0x3fe9000c0000-0x3fe9000dffff]
pci 0022:01:00.0: BAR 3: assigned [mem 0x3fe9000e0000-0x3fe9000e3fff]
pci 0022:01:00.0: BAR 2: no space for [io size 0x0020]
pci 0022:01:00.0: BAR 2: failed to assign [io size 0x0020]
e1000e 0022:01:00.0: pci_enable_device() blocked, no PE assigned.
e1000e: probe of 0022:01:00.0 failed with error -22
So on rescan we can re-discover the device, but the driver probe will
always fail at the point where the driver attemps to enable the device
because the PE was deconfigured.
Repeating this same experiment with this series (and dependency) applied:
/sys/devices/pci0022:00/0022:00:00.0 # echo 1 > rescan
pci 0022:01:00.0: [8086:10d3] type 00 class 0x020000
pci 0022:01:00.0: reg 0x10: [mem 0x3fe9000c0000-0x3fe9000dffff]
pci 0022:01:00.0: reg 0x14: [mem 0x3fe900000000-0x3fe90007ffff]
pci 0022:01:00.0: reg 0x18: [io 0x0000-0x001f]
pci 0022:01:00.0: reg 0x1c: [mem 0x3fe9000e0000-0x3fe9000e3fff]
pci 0022:01:00.0: reg 0x30: [mem 0x00000000-0x0003ffff pref]
pci 0022:01:00.0: BAR3 [mem size 0x00004000]: requesting alignment to 0x10000
pci 0022:01:00.0: PME# supported from D0 D3hot D3cold
pci 0022:00:00.0: BAR 13: no space for [io size 0x1000]
pci 0022:00:00.0: BAR 13: failed to assign [io size 0x1000]
pci 0022:01:00.0: BAR 1: assigned [mem 0x3fe900000000-0x3fe90007ffff]
pci 0022:01:00.0: BAR 6: assigned [mem 0x3fe900080000-0x3fe9000bffff pref]
pci 0022:01:00.0: BAR 0: assigned [mem 0x3fe9000c0000-0x3fe9000dffff]
pci 0022:01:00.0: BAR 3: assigned [mem 0x3fe9000e0000-0x3fe9000e3fff]
pci 0022:01:00.0: BAR 2: no space for [io size 0x0020]
pci 0022:01:00.0: BAR 2: failed to assign [io size 0x0020]
pci_bus 0022:01: Configuring PE for bus
pci 0022:01 : [PE# fd] Secondary bus 0x0000000000000001 associated with PE#fd
pci 0022:01 : [PE# fd] Setting up 32-bit TCE table at 0..80000000
pci 0022:01 : [PE# fd] Setting up window#0 0..7fffffffff pg=10000
pci 0022:01 : [PE# fd] Enabling 64-bit DMA bypass
pci 0022:01:00.0: Configured PE#fd
pci 0022:01:00.0: Adding to iommu group 12
e1000e 0022:01:00.0: enabling device (0140 -> 0142)
e1000e 0022:01:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
e1000e 0022:01:00.0 0022:01:00.0 (uninitialized): registered PHC clock
e1000e 0022:01:00.0 eth0: (PCI Express:2.5GT/s:Width x1) 68:05:ca:37:9c:d7
e1000e 0022:01:00.0 enP34p1s0: renamed from eth0
e1000e 0022:01:00.0 enP34p1s0: Intel(R) PRO/1000 Network Connection
e1000e 0022:01:00.0 enP34p1s0: MAC: 3, PHY: 8, PBA No: E46981-008
/sys/devices/pci0022:00/0022:00:00.0 #
Now, when the rescan happens we notice the PE was deconfigured after removing
the device and re-configure it. This allows the device to be enabled and
everything works. Probably.
Making this change also lays the groundwork for allowing devices to be
added to a bus PE as they're enabled rather than mapping all 256 devfns
on a bus to the PE in one go. This is going to be necessary for supporting
the native PCIe hotplug driver (rather than pnv_php) since currently
scanning an empty slot causes spurious PE freezes. Keeping inactive
devices mapped to the reserved PE would prevent that from occuring.
It might also be useful for (ab)using PEs to provide per-device
IOMMU contexts rather than per-bus. A per-device context would also be
necessary for allowing individual functions of a device to be passed
through to guests rather than requiring all of them to be passed as a
group.
Oliver
^ permalink raw reply
* [PATCH 1/4] powerpc/powernv/pci: Add helper to find ioda_pe from BDFN
From: Oliver O'Halloran @ 2020-04-17 7:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <20200417073508.30356-1-oohall@gmail.com>
For each PHB we maintain a reverse-map that can be used to find the
PE that a BDFN is currently mapped to. Add a helper for doing this
lookup so we can check if a PE has been configured without looking
at pdn->pe_number.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 10 ++++++++++
arch/powerpc/platforms/powernv/pci.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 8ae8836..934cbee 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -660,6 +660,16 @@ static int pnv_ioda_get_pe_state(struct pnv_phb *phb, int pe_no)
return state;
}
+struct pnv_ioda_pe *pnv_pci_bdfn_to_pe(struct pnv_phb *phb, u16 bdfn)
+{
+ int pe_number = phb->ioda.pe_rmap[bdfn];
+
+ if (pe_number == IODA_INVALID_PE)
+ return NULL;
+
+ return &phb->ioda.pe_array[pe_number];
+}
+
struct pnv_ioda_pe *pnv_ioda_get_pe(struct pci_dev *dev)
{
struct pci_controller *hose = pci_bus_to_host(dev->bus);
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index fc05f9b..83d40a0 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -208,6 +208,7 @@ extern int pnv_eeh_phb_reset(struct pci_controller *hose, int option);
extern int pnv_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type);
extern void pnv_teardown_msi_irqs(struct pci_dev *pdev);
+extern struct pnv_ioda_pe *pnv_pci_bdfn_to_pe(struct pnv_phb *phb, u16 bdfn);
extern struct pnv_ioda_pe *pnv_ioda_get_pe(struct pci_dev *dev);
extern void pnv_set_msi_irq_chip(struct pnv_phb *phb, unsigned int virq);
extern unsigned long pnv_pci_ioda2_get_table_size(__u32 page_shift,
--
2.9.5
^ permalink raw reply related
* [PATCH 2/4] powerpc/powernv/pci: Re-work bus PE configuration
From: Oliver O'Halloran @ 2020-04-17 7:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <20200417073508.30356-1-oohall@gmail.com>
For normal PHBs IODA PEs are handled on a per-bus basis so all the devices
on that bus will share a PE. Which PE specificly is determined by the location
of the MMIO BARs for the devices on the bus so we can't actually configure the
bus PEs until after MMIO resources are allocated. As a result PEs are currently
configured by pcibios_setup_bridge(), which is called just before the bridge
windows are programmed into the bus' parent bridge. Configuring the bus PE here
causes a few problems:
1. The root bus doesn't have a parent bridge so setting up the PE for the root
bus requires some hacks.
2. The PELT-V isn't setup correctly because pnv_ioda_set_peltv() assumes that
PEs will be configured in root-to-leaf order. This assumption is broken
because resource assignment is performed depth-first so the leaf bridges
are setup before their parents are. The hack mentioned in 1) results in
the "correct" PELT-V for busses immediately below the root port, but not
for devices below a switch.
3. It's possible to break the sysfs PCI rescan feature by removing all
the devices on a bus. When the last device is removed from a PE its
will be de-configured. Rescanning the devices on a bus does not cause
the bridge to be reconfigured rendering the devices on that bus
unusable.
We can address most of these problems by moving the PE setup out of
pcibios_setup_bridge() and into pcibios_bus_add_device(). This fixes 1)
and 2) because pcibios_bus_add_device() is called on each device in
root-to-leaf order so PEs for parent buses will always be configured
before their children. It also fixes 3) by ensuring the PE is
configured before initialising DMA for the device. In the event the PE
was de-configured due to removing all the devices in that PE it will
now be reconfigured when a new device is added since there's no
dependecy on the bridge_setup() hook being called.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 81 ++++++++++++-------------------
1 file changed, 30 insertions(+), 51 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 934cbee..2ba730c 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -51,6 +51,7 @@ static const char * const pnv_phb_names[] = { "IODA1", "IODA2", "NPU_NVLINK",
"NPU_OCAPI" };
static void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable);
+static void pnv_pci_configure_bus(struct pci_bus *bus);
void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
const char *fmt, ...)
@@ -1120,34 +1121,6 @@ static struct pnv_ioda_pe *pnv_ioda_setup_dev_PE(struct pci_dev *dev)
return pe;
}
-static void pnv_ioda_setup_same_PE(struct pci_bus *bus, struct pnv_ioda_pe *pe)
-{
- struct pci_dev *dev;
-
- list_for_each_entry(dev, &bus->devices, bus_list) {
- struct pci_dn *pdn = pci_get_pdn(dev);
-
- if (pdn == NULL) {
- pr_warn("%s: No device node associated with device !\n",
- pci_name(dev));
- continue;
- }
-
- /*
- * In partial hotplug case, the PCI device might be still
- * associated with the PE and needn't attach it to the PE
- * again.
- */
- if (pdn->pe_number != IODA_INVALID_PE)
- continue;
-
- pe->device_count++;
- pdn->pe_number = pe->pe_number;
- if ((pe->flags & PNV_IODA_PE_BUS_ALL) && dev->subordinate)
- pnv_ioda_setup_same_PE(dev->subordinate, pe);
- }
-}
-
/*
* There're 2 types of PCI bus sensitive PEs: One that is compromised of
* single PCI bus. Another one that contains the primary PCI bus and its
@@ -1168,7 +1141,6 @@ static struct pnv_ioda_pe *pnv_ioda_setup_bus_PE(struct pci_bus *bus, bool all)
pe_num = phb->ioda.pe_rmap[bus->number << 8];
if (pe_num != IODA_INVALID_PE) {
pe = &phb->ioda.pe_array[pe_num];
- pnv_ioda_setup_same_PE(bus, pe);
return NULL;
}
@@ -1212,9 +1184,6 @@ static struct pnv_ioda_pe *pnv_ioda_setup_bus_PE(struct pci_bus *bus, bool all)
return NULL;
}
- /* Associate it with all child devices */
- pnv_ioda_setup_same_PE(bus, pe);
-
/* Put PE to the list */
list_add_tail(&pe->list, &phb->ioda.pe_list);
@@ -1772,15 +1741,32 @@ static void pnv_pci_ioda_dma_dev_setup(struct pci_dev *pdev)
struct pci_dn *pdn = pci_get_pdn(pdev);
struct pnv_ioda_pe *pe;
- /*
- * The function can be called while the PE#
- * hasn't been assigned. Do nothing for the
- * case.
- */
- if (!pdn || pdn->pe_number == IODA_INVALID_PE)
- return;
+ /* Check if the BDFN for this device is associated with a PE yet */
+ pe = pnv_pci_bdfn_to_pe(phb, pdev->devfn | (pdev->bus->number << 8));
+ if (!pe) {
+ /* VF PEs should be pre-configured in pnv_pci_sriov_enable() */
+ if (WARN_ON(pdev->is_virtfn))
+ return;
+
+ pnv_pci_configure_bus(pdev->bus);
+ pe = pnv_pci_bdfn_to_pe(phb, pdev->devfn | (pdev->bus->number << 8));
+ pci_info(pdev, "Configured PE#%x\n", pe ? pe->pe_number : 0xfffff);
+
+
+ /*
+ * If we can't setup the IODA PE something has gone horribly
+ * wrong and we can't enable DMA for the device.
+ */
+ if (WARN_ON(!pe))
+ return;
+ } else {
+ pci_info(pdev, "Added to existing PE#%x\n", pe->pe_number);
+ }
+
+ if (pdn)
+ pdn->pe_number = pe->pe_number;
+ pe->device_count++;
- pe = &phb->ioda.pe_array[pdn->pe_number];
WARN_ON(get_dma_ops(&pdev->dev) != &dma_iommu_ops);
pdev->dev.archdata.dma_offset = pe->tce_bypass_base;
set_iommu_table_base(&pdev->dev, pe->table_group.tables[0]);
@@ -2300,9 +2286,6 @@ static void pnv_pci_ioda1_setup_dma_pe(struct pnv_phb *phb,
pe->table_group.tce32_size = tbl->it_size << tbl->it_page_shift;
iommu_init_table(tbl, phb->hose->node, 0, 0);
- if (pe->flags & (PNV_IODA_PE_BUS | PNV_IODA_PE_BUS_ALL))
- pnv_ioda_setup_bus_dma(pe, pe->pbus);
-
return;
fail:
/* XXX Failure: Try to fallback to 64-bit only ? */
@@ -2633,9 +2616,6 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
iommu_register_group(&pe->table_group, phb->hose->global_number,
pe->pe_number);
#endif
-
- if (pe->flags & (PNV_IODA_PE_BUS | PNV_IODA_PE_BUS_ALL))
- pnv_ioda_setup_bus_dma(pe, pe->pbus);
}
int64_t pnv_opal_pci_msi_eoi(struct irq_chip *chip, unsigned int hw_irq)
@@ -3234,16 +3214,15 @@ static void pnv_pci_fixup_bridge_resources(struct pci_bus *bus,
}
}
-static void pnv_pci_setup_bridge(struct pci_bus *bus, unsigned long type)
+static void pnv_pci_configure_bus(struct pci_bus *bus)
{
struct pci_controller *hose = pci_bus_to_host(bus);
struct pnv_phb *phb = hose->private_data;
struct pci_dev *bridge = bus->self;
struct pnv_ioda_pe *pe;
- bool all = (pci_pcie_type(bridge) == PCI_EXP_TYPE_PCI_BRIDGE);
+ bool all = (bridge && pci_pcie_type(bridge) == PCI_EXP_TYPE_PCI_BRIDGE);
- /* Extend bridge's windows if necessary */
- pnv_pci_fixup_bridge_resources(bus, type);
+ dev_info(&bus->dev, "Configuring PE for bus\n");
/* The PE for root bus should be realized before any one else */
if (!phb->ioda.root_pe_populated) {
@@ -3620,7 +3599,7 @@ static const struct pci_controller_ops pnv_pci_ioda_controller_ops = {
.enable_device_hook = pnv_pci_enable_device_hook,
.release_device = pnv_pci_release_device,
.window_alignment = pnv_pci_window_alignment,
- .setup_bridge = pnv_pci_setup_bridge,
+ .setup_bridge = pnv_pci_fixup_bridge_resources,
.reset_secondary_bus = pnv_pci_reset_secondary_bus,
.shutdown = pnv_pci_ioda_shutdown,
};
--
2.9.5
^ permalink raw reply related
* [PATCH 3/4] powerpc/powernv/pci: Reserve the root bus PE during init
From: Oliver O'Halloran @ 2020-04-17 7:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <20200417073508.30356-1-oohall@gmail.com>
Doing it once during boot rather than doing it on the fly and drop the janky
populated logic.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 26 +++++++++-----------------
arch/powerpc/platforms/powernv/pci.h | 1 -
2 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 2ba730c..05436a9 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1145,8 +1145,7 @@ static struct pnv_ioda_pe *pnv_ioda_setup_bus_PE(struct pci_bus *bus, bool all)
}
/* PE number for root bus should have been reserved */
- if (pci_is_root_bus(bus) &&
- phb->ioda.root_pe_idx != IODA_INVALID_PE)
+ if (pci_is_root_bus(bus))
pe = &phb->ioda.pe_array[phb->ioda.root_pe_idx];
/* Check if PE is determined by M64 */
@@ -3224,15 +3223,6 @@ static void pnv_pci_configure_bus(struct pci_bus *bus)
dev_info(&bus->dev, "Configuring PE for bus\n");
- /* The PE for root bus should be realized before any one else */
- if (!phb->ioda.root_pe_populated) {
- pe = pnv_ioda_setup_bus_PE(phb->hose->bus, false);
- if (pe) {
- phb->ioda.root_pe_idx = pe->pe_number;
- phb->ioda.root_pe_populated = true;
- }
- }
-
/* Don't assign PE to PCI bus, which doesn't have subordinate devices */
if (list_empty(&bus->devices))
return;
@@ -3517,11 +3507,10 @@ static void pnv_ioda_release_pe(struct pnv_ioda_pe *pe)
* that it can be populated again in PCI hot add path. The PE
* shouldn't be destroyed as it's the global reserved resource.
*/
- if (phb->ioda.root_pe_populated &&
- phb->ioda.root_pe_idx == pe->pe_number)
- phb->ioda.root_pe_populated = false;
- else
- pnv_ioda_free_pe(pe);
+ if (phb->ioda.root_pe_idx == pe->pe_number)
+ return;
+
+ pnv_ioda_free_pe(pe);
}
static void pnv_pci_release_device(struct pci_dev *pdev)
@@ -3629,6 +3618,7 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np,
struct pnv_phb *phb;
unsigned long size, m64map_off, m32map_off, pemap_off;
unsigned long iomap_off = 0, dma32map_off = 0;
+ struct pnv_ioda_pe *root_pe;
struct resource r;
const __be64 *prop64;
const __be32 *prop32;
@@ -3796,7 +3786,9 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np,
phb->ioda.root_pe_idx = phb->ioda.reserved_pe_idx - 1;
pnv_ioda_reserve_pe(phb, phb->ioda.root_pe_idx);
} else {
- phb->ioda.root_pe_idx = IODA_INVALID_PE;
+ /* otherwise just allocate one */
+ root_pe = pnv_ioda_alloc_pe(phb);
+ phb->ioda.root_pe_idx = root_pe->pe_number;
}
INIT_LIST_HEAD(&phb->ioda.pe_list);
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index 83d40a0..51c254f2 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -136,7 +136,6 @@ struct pnv_phb {
unsigned int total_pe_num;
unsigned int reserved_pe_idx;
unsigned int root_pe_idx;
- bool root_pe_populated;
/* 32-bit MMIO window */
unsigned int m32_size;
--
2.9.5
^ permalink raw reply related
* [PATCH 4/4] powerpc/powernv/pci: Sprinkle around some WARN_ON()s
From: Oliver O'Halloran @ 2020-04-17 7:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <20200417073508.30356-1-oohall@gmail.com>
pnv_pci_ioda_configure_bus() should now only ever be called when a device is
added to the bus so add a WARN_ON() to the empty bus check. Similarly,
pnv_pci_ioda_setup_bus_PE() should only ever be called for an unconfigured PE,
so add a WARN_ON() for that case too.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 05436a9..627420c 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1139,7 +1139,7 @@ static struct pnv_ioda_pe *pnv_ioda_setup_bus_PE(struct pci_bus *bus, bool all)
* We should reuse it instead of allocating a new one.
*/
pe_num = phb->ioda.pe_rmap[bus->number << 8];
- if (pe_num != IODA_INVALID_PE) {
+ if (WARN_ON(pe_num != IODA_INVALID_PE)) {
pe = &phb->ioda.pe_array[pe_num];
return NULL;
}
@@ -3224,7 +3224,7 @@ static void pnv_pci_configure_bus(struct pci_bus *bus)
dev_info(&bus->dev, "Configuring PE for bus\n");
/* Don't assign PE to PCI bus, which doesn't have subordinate devices */
- if (list_empty(&bus->devices))
+ if (WARN_ON(list_empty(&bus->devices)))
return;
/* Reserve PEs according to used M64 resources */
--
2.9.5
^ permalink raw reply related
* Re: [PATCH V2] vhost: do not enable VHOST_MENU by default
From: Jason Wang @ 2020-04-17 7:36 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-s390, tsbogend, gor, kvm, linux-kernel, heiko.carstens,
linux-mips, virtualization, borntraeger, geert, netdev, paulus,
linuxppc-dev
In-Reply-To: <20200417022929-mutt-send-email-mst@kernel.org>
On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:
> On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:
>> On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:
>>> On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote:
>>>> We try to keep the defconfig untouched after decoupling CONFIG_VHOST
>>>> out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
>>>> ("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
>>>> default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
>>>> without the caring of CONFIG_VHOST.
>>>>
>>>> But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
>>>> for the ones that doesn't want vhost. So it actually shifts the
>>>> burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
>>>> not set". So this patch tries to enable CONFIG_VHOST explicitly in
>>>> defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.
>>>>
>>>> Acked-by: Christian Borntraeger<borntraeger@de.ibm.com> (s390)
>>>> Acked-by: Michael Ellerman<mpe@ellerman.id.au> (powerpc)
>>>> Cc: Thomas Bogendoerfer<tsbogend@alpha.franken.de>
>>>> Cc: Benjamin Herrenschmidt<benh@kernel.crashing.org>
>>>> Cc: Paul Mackerras<paulus@samba.org>
>>>> Cc: Michael Ellerman<mpe@ellerman.id.au>
>>>> Cc: Heiko Carstens<heiko.carstens@de.ibm.com>
>>>> Cc: Vasily Gorbik<gor@linux.ibm.com>
>>>> Cc: Christian Borntraeger<borntraeger@de.ibm.com>
>>>> Reported-by: Geert Uytterhoeven<geert@linux-m68k.org>
>>>> Signed-off-by: Jason Wang<jasowang@redhat.com>
>>> I rebased this on top of OABI fix since that
>>> seems more orgent to fix.
>>> Pushed to my vhost branch pls take a look and
>>> if possible test.
>>> Thanks!
>>
>> I test this patch by generating the defconfigs that wants vhost_net or
>> vhost_vsock. All looks fine.
>>
>> But having CONFIG_VHOST_DPN=y may end up with the similar situation that
>> this patch want to address.
>> Maybe we can let CONFIG_VHOST depends on !ARM || AEABI then add another
>> menuconfig for VHOST_RING and do something similar?
>>
>> Thanks
> Sorry I don't understand. After this patch CONFIG_VHOST_DPN is just
> an internal variable for the OABI fix. I kept it separate
> so it's easy to revert for 5.8. Yes we could squash it into
> VHOST directly but I don't see how that changes logic at all.
Sorry for being unclear.
I meant since it was enabled by default, "CONFIG_VHOST_DPN=y" will be
left in the defconfigs. This requires the arch maintainers to add
"CONFIG_VHOST_VDPN is not set". (Geert complains about this)
Thanks
>
^ permalink raw reply
* Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram
From: Greg KH @ 2020-04-17 7:42 UTC (permalink / raw)
To: Scott Wood
Cc: Rob Herring, linux-kernel, kernel, 王文虎,
linuxppc-dev
In-Reply-To: <64bb1f056abd8bfab2befef5d1e6baec2056077f.camel@buserror.net>
On Thu, Apr 16, 2020 at 11:58:29PM -0500, Scott Wood wrote:
> On Fri, 2020-04-17 at 10:31 +0800, 王文虎 wrote:
> > > > On Thu, 2020-04-16 at 08:35 -0700, Wang Wenhu wrote:
> > > > > +#define UIO_INFO_VER "devicetree,pseudo"
> > > >
> > > > What does this mean? Changing a number into a non-obvious string (Why
> > > > "pseudo"? Why does the UIO user care that the config came from the
> > > > device
> > > > tree?) just to avoid setting off Greg's version number autoresponse
> > > > isn't
> > > > really helping anything.
> > > >
> > > > > +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
> > > > > + { .compatible = "uio,mpc85xx-cache-sram", },
> > >
> > > Form is <vendor>,<device> and "uio" is not a vendor (and never will be).
> > >
> >
> > Should have been something like "fsl,mpc85xx-cache-sram-uio", and if it is
> > to be defined with module parameters, this would be user defined.
> > Anyway, <vendor>,<device> should always be used.
> >
> > > > > + {},
> > > > > +};
> > > > > +
> > > > > +static struct platform_driver uio_fsl_85xx_cache_sram = {
> > > > > + .probe = uio_fsl_85xx_cache_sram_probe,
> > > > > + .remove = uio_fsl_85xx_cache_sram_remove,
> > > > > + .driver = {
> > > > > + .name = DRIVER_NAME,
> > > > > + .owner = THIS_MODULE,
> > > > > + .of_match_table = uio_mpc85xx_l2ctlr_of_match,
> > > > > + },
> > > > > +};
> > > >
> > > > Greg's comment notwithstanding, I really don't think this belongs in the
> > > > device tree (and if I do get overruled on that point, it at least needs
> > > > a
> > > > binding document). Let me try to come up with a patch for dynamic
> > > > allocation.
> > >
> > > Agreed. "UIO" bindings have long been rejected.
> > >
> >
> > Sounds it is. And does the modification below fit well?
> > ---
> > -static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
> > - { .compatible = "uio,mpc85xx-cache-sram", },
> > - {},
> > +#ifdef CONFIG_OF
> > +static struct of_device_id uio_fsl_85xx_cache_sram_of_match[] = {
> > + { /* This is filled with module_parm */ },
> > + { /* Sentinel */ },
> > };
> > +MODULE_DEVICE_TABLE(of, uio_fsl_85xx_cache_sram_of_match);
> > +module_param_string(of_id, uio_fsl_85xx_cache_sram_of_match[0].compatible,
> > + sizeof(uio_fsl_85xx_cache_sram_of_match[0].compa
> > tible), 0);
> > +MODULE_PARM_DESC(of_id, "platform device id to be handled by cache-sram-
> > uio");
> > +#endif
>
> No. The point is that you wouldn't be configuring this with the device tree
> at all.
Wait, why not? Don't force people to use module parameters, that is
crazy. DT describes the hardware involved, if someone wants to bind to
a specific range of memory, as described by DT, why can't they do so?
I can understand not liking the name "uio" in a dt tree, but there's no
reason that DT can not describe what a driver binds to here.
Remember, module parameters are NEVER the answer, this isn't the 1990's
anymore.
thanks,
greg k-h
^ permalink raw reply
* Re:[PATCH v5,4/4] drivers: uio: new driver for fsl_85xx_cache_sram
From: 王文虎 @ 2020-04-17 7:42 UTC (permalink / raw)
To: Wang Wenhu; +Cc: robh, gregkh, linux-kernel, oss, kernel, linuxppc-dev
In-Reply-To: <20200417071616.44598-5-wenhu.wang@vivo.com>
>A driver for freescale 85xx platforms to access the Cache-Sram form>user level. This is extremely helpful for some user-space applications
>that require high performance memory accesses.
>
>Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>Cc: Christophe Leroy <christophe.leroy@c-s.fr>
>Cc: Scott Wood <oss@buserror.net>
>Cc: Michael Ellerman <mpe@ellerman.id.au>
>Cc: linuxppc-dev@lists.ozlabs.org
>Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
>Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
Hi, Christophe,
I labeled you Reviewed comment.
Regards,
Wenhu
>---
>Changes since v1:
> * Addressed comments from Greg K-H
> * Moved kfree(info->name) into uio_info_free_internal()
>Changes since v2:
> * Addressed comments from Greg, Scott and Christophe
> * Use "uiomem->internal_addr" as if condition for sram memory free,
> and memset the uiomem entry
> * of_match_table modified to be apart from HW info which belong to
> the HW level driver fsl_85xx_cache_sram to match
> * Use roundup_pow_of_two for align calc
> * Remove useless clear block of uiomem entries.
> * Use UIO_INFO_VER micro for info->version, and define it as
> "devicetree,pseudo", meaning this is pseudo device and probed from
> device tree configuration
>Changes since v3:
> * Addressed comments from Christophe(use devm_xxx memory alloc interfaces)
>Changes since v4:
> * Use module_param_string for of_match_table, no binding to devicetree
>---
> drivers/uio/Kconfig | 9 ++
> drivers/uio/Makefile | 1 +
> drivers/uio/uio_fsl_85xx_cache_sram.c | 154 ++++++++++++++++++++++++++
> 3 files changed, 164 insertions(+)
> create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
>
>diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
>index 202ee81cfc2b..9c3b47461b71 100644
>--- a/drivers/uio/Kconfig
>+++ b/drivers/uio/Kconfig
>@@ -105,6 +105,15 @@ config UIO_NETX
> To compile this driver as a module, choose M here; the module
> will be called uio_netx.
>
>+config UIO_FSL_85XX_CACHE_SRAM
>+ tristate "Freescale 85xx Cache-Sram driver"
>+ depends on FSL_SOC_BOOKE && PPC32
>+ select FSL_85XX_CACHE_SRAM
>+ help
>+ Generic driver for accessing the Cache-Sram form user level. This
>+ is extremely helpful for some user-space applications that require
>+ high performance memory accesses.
>+
> config UIO_FSL_ELBC_GPCM
> tristate "eLBC/GPCM driver"
> depends on FSL_LBC
>diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
>index c285dd2a4539..be2056cffc21 100644
>--- a/drivers/uio/Makefile
>+++ b/drivers/uio/Makefile
>@@ -10,4 +10,5 @@ obj-$(CONFIG_UIO_NETX) += uio_netx.o
> obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
> obj-$(CONFIG_UIO_MF624) += uio_mf624.o
> obj-$(CONFIG_UIO_FSL_ELBC_GPCM) += uio_fsl_elbc_gpcm.o
>+obj-$(CONFIG_UIO_FSL_85XX_CACHE_SRAM) += uio_fsl_85xx_cache_sram.o
> obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o
>diff --git a/drivers/uio/uio_fsl_85xx_cache_sram.c b/drivers/uio/uio_fsl_85xx_cache_sram.c
>new file mode 100644
>index 000000000000..4db3648629b3
>--- /dev/null
>+++ b/drivers/uio/uio_fsl_85xx_cache_sram.c
>@@ -0,0 +1,154 @@
>+// SPDX-License-Identifier: GPL-2.0
>+/*
>+ * Copyright (C) 2020 Vivo Communication Technology Co. Ltd.
>+ * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.com>
>+ * All rights reserved.
>+ */
>+
>+#include <linux/platform_device.h>
>+#include <linux/uio_driver.h>
>+#include <linux/stringify.h>
>+#include <linux/module.h>
>+#include <linux/kernel.h>
>+#include <asm/fsl_85xx_cache_sram.h>
>+
>+#define DRIVER_NAME "uio_fsl_85xx_cache_sram"
>+#define UIO_INFO_VER "devicetree,pseudo"
>+#define UIO_NAME "uio_cache_sram"
>+
>+static void uio_info_free_internal(struct uio_info *info)
>+{
>+ int i;
>+
>+ for (i = 0; i < MAX_UIO_MAPS; i++) {
>+ struct uio_mem *uiomem = &info->mem[i];
>+
>+ if (uiomem->internal_addr) {
>+ mpc85xx_cache_sram_free(uiomem->internal_addr);
>+ memset(uiomem, 0, sizeof(*uiomem));
>+ }
>+ }
>+}
>+
>+static int uio_fsl_85xx_cache_sram_probe(struct platform_device *pdev)
>+{
>+ struct device_node *parent = pdev->dev.of_node;
>+ struct device_node *node = NULL;
>+ struct uio_info *info;
>+ struct uio_mem *uiomem;
>+ const char *dt_name;
>+ u32 mem_size;
>+ int ret;
>+
>+ /* alloc uio_info for one device */
>+ info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
>+ if (!info)
>+ return -ENOMEM;
>+
>+ /* get optional uio name */
>+ if (of_property_read_string(parent, "uio_name", &dt_name))
>+ dt_name = UIO_NAME;
>+
>+ info->name = devm_kstrdup(&pdev->dev, dt_name, GFP_KERNEL);
>+ if (!info->name)
>+ return -ENOMEM;
>+
>+ uiomem = info->mem;
>+ for_each_child_of_node(parent, node) {
>+ void *virt;
>+ phys_addr_t phys;
>+
>+ ret = of_property_read_u32(node, "cache-mem-size", &mem_size);
>+ if (ret) {
>+ ret = -EINVAL;
>+ goto err_out;
>+ }
>+
>+ if (mem_size == 0) {
>+ dev_err(&pdev->dev, "error cache-mem-size should not be 0\n");
>+ ret = -EINVAL;
>+ goto err_out;
>+ }
>+
>+ virt = mpc85xx_cache_sram_alloc(mem_size, &phys,
>+ roundup_pow_of_two(mem_size));
>+ if (!virt) {
>+ /* mpc85xx_cache_sram_alloc to define the real cause */
>+ ret = -ENOMEM;
>+ goto err_out;
>+ }
>+
>+ uiomem->memtype = UIO_MEM_PHYS;
>+ uiomem->addr = phys;
>+ uiomem->size = mem_size;
>+ uiomem->name = kstrdup(node->name, GFP_KERNEL);
>+ uiomem->internal_addr = virt;
>+ uiomem++;
>+
>+ if (uiomem >= &info->mem[MAX_UIO_MAPS]) {
>+ dev_warn(&pdev->dev, "more than %d uio-maps for device.\n",
>+ MAX_UIO_MAPS);
>+ break;
>+ }
>+ }
>+
>+ if (uiomem == info->mem) {
>+ dev_err(&pdev->dev, "error no valid uio-map configuration found\n");
>+ return -EINVAL;
>+ }
>+
>+ info->version = UIO_INFO_VER;
>+
>+ /* register uio device */
>+ if (uio_register_device(&pdev->dev, info)) {
>+ dev_err(&pdev->dev, "error uio,cache-sram registration failed\n");
>+ ret = -ENODEV;
>+ goto err_out;
>+ }
>+
>+ platform_set_drvdata(pdev, info);
>+
>+ return 0;
>+err_out:
>+ uio_info_free_internal(info);
>+ return ret;
>+}
>+
>+static int uio_fsl_85xx_cache_sram_remove(struct platform_device *pdev)
>+{
>+ struct uio_info *info = platform_get_drvdata(pdev);
>+
>+ uio_unregister_device(info);
>+
>+ uio_info_free_internal(info);
>+
>+ return 0;
>+}
>+
>+#ifdef CONFIG_OF
>+static struct of_device_id uio_fsl_85xx_cache_sram_of_match[] = {
>+ { /* This is filled with module_parm */ },
>+ { /* Sentinel */ },
>+};
>+MODULE_DEVICE_TABLE(of, uio_fsl_85xx_cache_sram_of_match);
>+
>+module_param_string(of_id, uio_fsl_85xx_cache_sram_of_match[0].compatible,
>+ sizeof(uio_fsl_85xx_cache_sram_of_match[0].compatible), 0);
>+MODULE_PARM_DESC(of_id, "platform device id to be handled by cache-sram-uio");
>+#endif
>+
>+static struct platform_driver uio_fsl_85xx_cache_sram = {
>+ .probe = uio_fsl_85xx_cache_sram_probe,
>+ .remove = uio_fsl_85xx_cache_sram_remove,
>+ .driver = {
>+ .name = DRIVER_NAME,
>+ .of_match_table = of_match_ptr(uio_fsl_85xx_cache_sram_of_match),
>+ },
>+};
>+
>+module_platform_driver(uio_fsl_85xx_cache_sram);
>+
>+MODULE_AUTHOR("Wang Wenhu <wenhu.wang@vivo.com>");
>+MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver");
>+MODULE_ALIAS("platform:" DRIVER_NAME);
>+MODULE_LICENSE("GPL v2");
>--
>2.17.1
>
^ permalink raw reply
* Re: [PATCH 1/4] dma-mapping: move the remaining DMA API calls out of line
From: Christoph Hellwig @ 2020-04-17 7:58 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Greg Kroah-Hartman, Joerg Roedel, Robin Murphy, linux-kernel,
iommu, linuxppc-dev, Christoph Hellwig, Lu Baolu
In-Reply-To: <5139e8e1-6389-3387-dc39-6983b08ff28d@ozlabs.ru>
On Wed, Apr 15, 2020 at 09:21:37PM +1000, Alexey Kardashevskiy wrote:
> And the fact they were exported leaves possibility that there is a
> driver somewhere relying on these symbols or distro kernel won't build
> because the symbol disappeared from exports (I do not know what KABI
> guarantees or if mainline kernel cares).
We absolutely do not care. In fact for abuses of APIs that drivers
should not use we almost care to make them private and break people
abusing them.
> I do not care in particular but
> some might, a line separated with empty lines in the commit log would do.
I'll add a blurb for the next version.
^ permalink raw reply
* Re: [PATCH V2] vhost: do not enable VHOST_MENU by default
From: Michael S. Tsirkin @ 2020-04-17 8:29 UTC (permalink / raw)
To: Jason Wang
Cc: linux-s390, tsbogend, gor, kvm, linux-kernel, heiko.carstens,
linux-mips, virtualization, borntraeger, geert, netdev, paulus,
linuxppc-dev
In-Reply-To: <4274625d-6feb-81b6-5b0a-695229e7c33d@redhat.com>
On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:
>
> On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:
> > On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:
> > > On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:
> > > > On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote:
> > > > > We try to keep the defconfig untouched after decoupling CONFIG_VHOST
> > > > > out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
> > > > > ("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
> > > > > default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
> > > > > without the caring of CONFIG_VHOST.
> > > > >
> > > > > But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
> > > > > for the ones that doesn't want vhost. So it actually shifts the
> > > > > burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
> > > > > not set". So this patch tries to enable CONFIG_VHOST explicitly in
> > > > > defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.
> > > > >
> > > > > Acked-by: Christian Borntraeger<borntraeger@de.ibm.com> (s390)
> > > > > Acked-by: Michael Ellerman<mpe@ellerman.id.au> (powerpc)
> > > > > Cc: Thomas Bogendoerfer<tsbogend@alpha.franken.de>
> > > > > Cc: Benjamin Herrenschmidt<benh@kernel.crashing.org>
> > > > > Cc: Paul Mackerras<paulus@samba.org>
> > > > > Cc: Michael Ellerman<mpe@ellerman.id.au>
> > > > > Cc: Heiko Carstens<heiko.carstens@de.ibm.com>
> > > > > Cc: Vasily Gorbik<gor@linux.ibm.com>
> > > > > Cc: Christian Borntraeger<borntraeger@de.ibm.com>
> > > > > Reported-by: Geert Uytterhoeven<geert@linux-m68k.org>
> > > > > Signed-off-by: Jason Wang<jasowang@redhat.com>
> > > > I rebased this on top of OABI fix since that
> > > > seems more orgent to fix.
> > > > Pushed to my vhost branch pls take a look and
> > > > if possible test.
> > > > Thanks!
> > >
> > > I test this patch by generating the defconfigs that wants vhost_net or
> > > vhost_vsock. All looks fine.
> > >
> > > But having CONFIG_VHOST_DPN=y may end up with the similar situation that
> > > this patch want to address.
> > > Maybe we can let CONFIG_VHOST depends on !ARM || AEABI then add another
> > > menuconfig for VHOST_RING and do something similar?
> > >
> > > Thanks
> > Sorry I don't understand. After this patch CONFIG_VHOST_DPN is just
> > an internal variable for the OABI fix. I kept it separate
> > so it's easy to revert for 5.8. Yes we could squash it into
> > VHOST directly but I don't see how that changes logic at all.
>
>
> Sorry for being unclear.
>
> I meant since it was enabled by default, "CONFIG_VHOST_DPN=y" will be left
> in the defconfigs.
But who cares? That does not add any code, does it?
> This requires the arch maintainers to add
> "CONFIG_VHOST_VDPN is not set". (Geert complains about this)
>
> Thanks
>
>
> >
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Florian Weimer @ 2020-04-17 8:34 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Rich Felker, libc-alpha, musl, Nicholas Piggin, libc-dev,
linuxppc-dev
In-Reply-To: <20200417014831.GL26902@gate.crashing.org>
* Segher Boessenkool:
> On Thu, Apr 16, 2020 at 08:34:42PM -0400, Rich Felker wrote:
>> On Thu, Apr 16, 2020 at 06:02:35PM -0500, Segher Boessenkool wrote:
>> > On Thu, Apr 16, 2020 at 08:12:19PM +0200, Florian Weimer wrote:
>> > > > I think my choice would be just making the inline syscall be a single
>> > > > call insn to an asm source file that out-of-lines the loading of TOC
>> > > > pointer and call through it or branch based on hwcap so that it's not
>> > > > repeated all over the place.
>> > >
>> > > I don't know how problematic control flow out of an inline asm is on
>> > > POWER. But this is basically the -moutline-atomics approach.
>> >
>> > Control flow out of inline asm (other than with "asm goto") is not
>> > allowed at all, just like on any other target (and will not work in
>> > practice, either -- just like on any other target). But the suggestion
>> > was to use actual assembler code, not inline asm?
>>
>> Calling it control flow out of inline asm is something of a misnomer.
>> The enclosing state is not discarded or altered; the asm statement
>> exits normally, reaching the next instruction in the enclosing
>> block/function as soon as the call from the asm statement returns,
>> with all register/clobber constraints satisfied.
>
> Ah. That should always Just Work, then -- our ABIs guarantee you can.
After thinking about it, I agree: GCC will handle spilling of the link
register. Branch-and-link instructions do not clobber the protected
zone, so no stack adjustment is needed (which would be problematic to
reflect in the unwind information).
Of course, the target function has to be written in assembler because
it must not use a regular stack frame.
^ permalink raw reply
* Re: [PATCH V2] vhost: do not enable VHOST_MENU by default
From: Jason Wang @ 2020-04-17 8:39 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-s390, tsbogend, gor, kvm, linux-kernel, heiko.carstens,
linux-mips, virtualization, borntraeger, geert, netdev, paulus,
linuxppc-dev
In-Reply-To: <20200417042912-mutt-send-email-mst@kernel.org>
On 2020/4/17 下午4:29, Michael S. Tsirkin wrote:
> On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:
>> On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:
>>> On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:
>>>> On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:
>>>>> On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote:
>>>>>> We try to keep the defconfig untouched after decoupling CONFIG_VHOST
>>>>>> out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
>>>>>> ("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
>>>>>> default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
>>>>>> without the caring of CONFIG_VHOST.
>>>>>>
>>>>>> But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
>>>>>> for the ones that doesn't want vhost. So it actually shifts the
>>>>>> burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
>>>>>> not set". So this patch tries to enable CONFIG_VHOST explicitly in
>>>>>> defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.
>>>>>>
>>>>>> Acked-by: Christian Borntraeger<borntraeger@de.ibm.com> (s390)
>>>>>> Acked-by: Michael Ellerman<mpe@ellerman.id.au> (powerpc)
>>>>>> Cc: Thomas Bogendoerfer<tsbogend@alpha.franken.de>
>>>>>> Cc: Benjamin Herrenschmidt<benh@kernel.crashing.org>
>>>>>> Cc: Paul Mackerras<paulus@samba.org>
>>>>>> Cc: Michael Ellerman<mpe@ellerman.id.au>
>>>>>> Cc: Heiko Carstens<heiko.carstens@de.ibm.com>
>>>>>> Cc: Vasily Gorbik<gor@linux.ibm.com>
>>>>>> Cc: Christian Borntraeger<borntraeger@de.ibm.com>
>>>>>> Reported-by: Geert Uytterhoeven<geert@linux-m68k.org>
>>>>>> Signed-off-by: Jason Wang<jasowang@redhat.com>
>>>>> I rebased this on top of OABI fix since that
>>>>> seems more orgent to fix.
>>>>> Pushed to my vhost branch pls take a look and
>>>>> if possible test.
>>>>> Thanks!
>>>> I test this patch by generating the defconfigs that wants vhost_net or
>>>> vhost_vsock. All looks fine.
>>>>
>>>> But having CONFIG_VHOST_DPN=y may end up with the similar situation that
>>>> this patch want to address.
>>>> Maybe we can let CONFIG_VHOST depends on !ARM || AEABI then add another
>>>> menuconfig for VHOST_RING and do something similar?
>>>>
>>>> Thanks
>>> Sorry I don't understand. After this patch CONFIG_VHOST_DPN is just
>>> an internal variable for the OABI fix. I kept it separate
>>> so it's easy to revert for 5.8. Yes we could squash it into
>>> VHOST directly but I don't see how that changes logic at all.
>>
>> Sorry for being unclear.
>>
>> I meant since it was enabled by default, "CONFIG_VHOST_DPN=y" will be left
>> in the defconfigs.
> But who cares?
FYI, please see https://www.spinics.net/lists/kvm/msg212685.html
> That does not add any code, does it?
It doesn't.
Thanks
>
>> This requires the arch maintainers to add
>> "CONFIG_VHOST_VDPN is not set". (Geert complains about this)
>>
>> Thanks
>>
>>
^ permalink raw reply
* Re: [PATCH V2] vhost: do not enable VHOST_MENU by default
From: Michael S. Tsirkin @ 2020-04-17 8:46 UTC (permalink / raw)
To: Jason Wang
Cc: linux-s390, tsbogend, gor, kvm, linux-kernel, heiko.carstens,
linux-mips, virtualization, borntraeger, geert, netdev, paulus,
linuxppc-dev
In-Reply-To: <fdb555a6-4b8d-15b6-0849-3fe0e0786038@redhat.com>
On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote:
>
> On 2020/4/17 下午4:29, Michael S. Tsirkin wrote:
> > On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:
> > > On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:
> > > > On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:
> > > > > On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:
> > > > > > On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote:
> > > > > > > We try to keep the defconfig untouched after decoupling CONFIG_VHOST
> > > > > > > out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
> > > > > > > ("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
> > > > > > > default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
> > > > > > > without the caring of CONFIG_VHOST.
> > > > > > >
> > > > > > > But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
> > > > > > > for the ones that doesn't want vhost. So it actually shifts the
> > > > > > > burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
> > > > > > > not set". So this patch tries to enable CONFIG_VHOST explicitly in
> > > > > > > defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.
> > > > > > >
> > > > > > > Acked-by: Christian Borntraeger<borntraeger@de.ibm.com> (s390)
> > > > > > > Acked-by: Michael Ellerman<mpe@ellerman.id.au> (powerpc)
> > > > > > > Cc: Thomas Bogendoerfer<tsbogend@alpha.franken.de>
> > > > > > > Cc: Benjamin Herrenschmidt<benh@kernel.crashing.org>
> > > > > > > Cc: Paul Mackerras<paulus@samba.org>
> > > > > > > Cc: Michael Ellerman<mpe@ellerman.id.au>
> > > > > > > Cc: Heiko Carstens<heiko.carstens@de.ibm.com>
> > > > > > > Cc: Vasily Gorbik<gor@linux.ibm.com>
> > > > > > > Cc: Christian Borntraeger<borntraeger@de.ibm.com>
> > > > > > > Reported-by: Geert Uytterhoeven<geert@linux-m68k.org>
> > > > > > > Signed-off-by: Jason Wang<jasowang@redhat.com>
> > > > > > I rebased this on top of OABI fix since that
> > > > > > seems more orgent to fix.
> > > > > > Pushed to my vhost branch pls take a look and
> > > > > > if possible test.
> > > > > > Thanks!
> > > > > I test this patch by generating the defconfigs that wants vhost_net or
> > > > > vhost_vsock. All looks fine.
> > > > >
> > > > > But having CONFIG_VHOST_DPN=y may end up with the similar situation that
> > > > > this patch want to address.
> > > > > Maybe we can let CONFIG_VHOST depends on !ARM || AEABI then add another
> > > > > menuconfig for VHOST_RING and do something similar?
> > > > >
> > > > > Thanks
> > > > Sorry I don't understand. After this patch CONFIG_VHOST_DPN is just
> > > > an internal variable for the OABI fix. I kept it separate
> > > > so it's easy to revert for 5.8. Yes we could squash it into
> > > > VHOST directly but I don't see how that changes logic at all.
> > >
> > > Sorry for being unclear.
> > >
> > > I meant since it was enabled by default, "CONFIG_VHOST_DPN=y" will be left
> > > in the defconfigs.
> > But who cares?
>
>
> FYI, please see https://www.spinics.net/lists/kvm/msg212685.html
The complaint was not about the symbol IIUC. It was that we caused
everyone to build vhost unless they manually disabled it.
>
> > That does not add any code, does it?
>
>
> It doesn't.
>
> Thanks
>
>
> >
> > > This requires the arch maintainers to add
> > > "CONFIG_VHOST_VDPN is not set". (Geert complains about this)
> > >
> > > Thanks
> > >
> > >
^ permalink raw reply
* Re: [PATCH V2] vhost: do not enable VHOST_MENU by default
From: Jason Wang @ 2020-04-17 8:51 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-s390, tsbogend, gor, kvm, linux-kernel, heiko.carstens,
linux-mips, virtualization, borntraeger, geert, netdev, paulus,
linuxppc-dev
In-Reply-To: <20200417044230-mutt-send-email-mst@kernel.org>
On 2020/4/17 下午4:46, Michael S. Tsirkin wrote:
> On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote:
>> On 2020/4/17 下午4:29, Michael S. Tsirkin wrote:
>>> On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:
>>>> On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:
>>>>> On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:
>>>>>> On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:
>>>>>>> On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote:
>>>>>>>> We try to keep the defconfig untouched after decoupling CONFIG_VHOST
>>>>>>>> out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
>>>>>>>> ("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
>>>>>>>> default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
>>>>>>>> without the caring of CONFIG_VHOST.
>>>>>>>>
>>>>>>>> But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
>>>>>>>> for the ones that doesn't want vhost. So it actually shifts the
>>>>>>>> burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
>>>>>>>> not set". So this patch tries to enable CONFIG_VHOST explicitly in
>>>>>>>> defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.
>>>>>>>>
>>>>>>>> Acked-by: Christian Borntraeger<borntraeger@de.ibm.com> (s390)
>>>>>>>> Acked-by: Michael Ellerman<mpe@ellerman.id.au> (powerpc)
>>>>>>>> Cc: Thomas Bogendoerfer<tsbogend@alpha.franken.de>
>>>>>>>> Cc: Benjamin Herrenschmidt<benh@kernel.crashing.org>
>>>>>>>> Cc: Paul Mackerras<paulus@samba.org>
>>>>>>>> Cc: Michael Ellerman<mpe@ellerman.id.au>
>>>>>>>> Cc: Heiko Carstens<heiko.carstens@de.ibm.com>
>>>>>>>> Cc: Vasily Gorbik<gor@linux.ibm.com>
>>>>>>>> Cc: Christian Borntraeger<borntraeger@de.ibm.com>
>>>>>>>> Reported-by: Geert Uytterhoeven<geert@linux-m68k.org>
>>>>>>>> Signed-off-by: Jason Wang<jasowang@redhat.com>
>>>>>>> I rebased this on top of OABI fix since that
>>>>>>> seems more orgent to fix.
>>>>>>> Pushed to my vhost branch pls take a look and
>>>>>>> if possible test.
>>>>>>> Thanks!
>>>>>> I test this patch by generating the defconfigs that wants vhost_net or
>>>>>> vhost_vsock. All looks fine.
>>>>>>
>>>>>> But having CONFIG_VHOST_DPN=y may end up with the similar situation that
>>>>>> this patch want to address.
>>>>>> Maybe we can let CONFIG_VHOST depends on !ARM || AEABI then add another
>>>>>> menuconfig for VHOST_RING and do something similar?
>>>>>>
>>>>>> Thanks
>>>>> Sorry I don't understand. After this patch CONFIG_VHOST_DPN is just
>>>>> an internal variable for the OABI fix. I kept it separate
>>>>> so it's easy to revert for 5.8. Yes we could squash it into
>>>>> VHOST directly but I don't see how that changes logic at all.
>>>> Sorry for being unclear.
>>>>
>>>> I meant since it was enabled by default, "CONFIG_VHOST_DPN=y" will be left
>>>> in the defconfigs.
>>> But who cares?
>> FYI, please seehttps://www.spinics.net/lists/kvm/msg212685.html
> The complaint was not about the symbol IIUC. It was that we caused
> everyone to build vhost unless they manually disabled it.
There could be some misunderstanding here. I thought it's somehow
similar: a CONFIG_VHOST_MENU=y will be left in the defconfigs even if
CONFIG_VHOST is not set.
Thanks
>
^ permalink raw reply
* [PATCH v6 0/9] crypto/nx: Enable GZIP engine and provide userpace API
From: Haren Myneni @ 2020-04-17 8:55 UTC (permalink / raw)
To: mpe, herbert; +Cc: mikey, npiggin, linux-crypto, sukadev, linuxppc-dev, dja
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 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 determines 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.
Changelog:
V2:
- Move user space API code to powerpc as suggested. Also this API
can be extended to any other coprocessor type that VAS can support
in future. Example: Fast thread wakeup feature from VAS
- Rebased to 5.6-rc3
V3:
- Fix sparse warnings (patches 3&6)
V4:
- Remove unused coproc_instid and add only window address in
fp->private_data.
- Add NX User's manual and Copy/paste links in VAS API documentation
in patch and other changes as Daniel Axtens suggested
V5:
- Added "NX Fault handling" section in VAS API documentation as Nick
suggested.
- Documentation: mmap size should be PAGE_SIZE as Daniel Axtens pointed.
V6:
- Make ioctl generic to support any coprocessor type (Michael Ellerman)
(patches 3&7)
Haren Myneni (9):
powerpc/vas: Initialize window attributes for GZIP coprocessor type
powerpc/vas: Define VAS_TX_WIN_OPEN ioctl API
powerpc/vas: Add VAS user space API
crypto/nx: Initialize coproc entry with kzalloc
crypto/nx: Rename nx-842-powernv file name to nx-common-powernv
crypto/nx: Make enable code generic to add new GZIP compression type
crypto/nx: Enable and setup GZIP compresstion type
crypto/nx: Remove 'pid' in vas_tx_win_attr struct
Documentation/powerpc: VAS API
Documentation/powerpc/index.rst | 1 +
Documentation/powerpc/vas-api.rst | 292 +++++
Documentation/userspace-api/ioctl/ioctl-number.rst | 1 +
arch/powerpc/include/asm/vas.h | 13 +-
arch/powerpc/include/uapi/asm/vas-api.h | 22 +
arch/powerpc/platforms/powernv/Makefile | 2 +-
arch/powerpc/platforms/powernv/vas-api.c | 278 +++++
arch/powerpc/platforms/powernv/vas-window.c | 23 +-
arch/powerpc/platforms/powernv/vas.h | 2 +
drivers/crypto/nx/Makefile | 2 +-
drivers/crypto/nx/nx-842-powernv.c | 1062 ------------------
drivers/crypto/nx/nx-common-powernv.c | 1136 ++++++++++++++++++++
12 files changed, 1761 insertions(+), 1073 deletions(-)
create mode 100644 Documentation/powerpc/vas-api.rst
create mode 100644 arch/powerpc/include/uapi/asm/vas-api.h
create mode 100644 arch/powerpc/platforms/powernv/vas-api.c
delete mode 100644 drivers/crypto/nx/nx-842-powernv.c
create mode 100644 drivers/crypto/nx/nx-common-powernv.c
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH V2] vhost: do not enable VHOST_MENU by default
From: Michael S. Tsirkin @ 2020-04-17 8:57 UTC (permalink / raw)
To: Jason Wang
Cc: linux-s390, tsbogend, gor, kvm, linux-kernel, heiko.carstens,
linux-mips, virtualization, borntraeger, geert, netdev, paulus,
linuxppc-dev
In-Reply-To: <73843240-3040-655d-baa9-683341ed4786@redhat.com>
On Fri, Apr 17, 2020 at 04:51:19PM +0800, Jason Wang wrote:
>
> On 2020/4/17 下午4:46, Michael S. Tsirkin wrote:
> > On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote:
> > > On 2020/4/17 下午4:29, Michael S. Tsirkin wrote:
> > > > On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:
> > > > > On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:
> > > > > > On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:
> > > > > > > On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:
> > > > > > > > On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote:
> > > > > > > > > We try to keep the defconfig untouched after decoupling CONFIG_VHOST
> > > > > > > > > out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
> > > > > > > > > ("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
> > > > > > > > > default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
> > > > > > > > > without the caring of CONFIG_VHOST.
> > > > > > > > >
> > > > > > > > > But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
> > > > > > > > > for the ones that doesn't want vhost. So it actually shifts the
> > > > > > > > > burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
> > > > > > > > > not set". So this patch tries to enable CONFIG_VHOST explicitly in
> > > > > > > > > defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.
> > > > > > > > >
> > > > > > > > > Acked-by: Christian Borntraeger<borntraeger@de.ibm.com> (s390)
> > > > > > > > > Acked-by: Michael Ellerman<mpe@ellerman.id.au> (powerpc)
> > > > > > > > > Cc: Thomas Bogendoerfer<tsbogend@alpha.franken.de>
> > > > > > > > > Cc: Benjamin Herrenschmidt<benh@kernel.crashing.org>
> > > > > > > > > Cc: Paul Mackerras<paulus@samba.org>
> > > > > > > > > Cc: Michael Ellerman<mpe@ellerman.id.au>
> > > > > > > > > Cc: Heiko Carstens<heiko.carstens@de.ibm.com>
> > > > > > > > > Cc: Vasily Gorbik<gor@linux.ibm.com>
> > > > > > > > > Cc: Christian Borntraeger<borntraeger@de.ibm.com>
> > > > > > > > > Reported-by: Geert Uytterhoeven<geert@linux-m68k.org>
> > > > > > > > > Signed-off-by: Jason Wang<jasowang@redhat.com>
> > > > > > > > I rebased this on top of OABI fix since that
> > > > > > > > seems more orgent to fix.
> > > > > > > > Pushed to my vhost branch pls take a look and
> > > > > > > > if possible test.
> > > > > > > > Thanks!
> > > > > > > I test this patch by generating the defconfigs that wants vhost_net or
> > > > > > > vhost_vsock. All looks fine.
> > > > > > >
> > > > > > > But having CONFIG_VHOST_DPN=y may end up with the similar situation that
> > > > > > > this patch want to address.
> > > > > > > Maybe we can let CONFIG_VHOST depends on !ARM || AEABI then add another
> > > > > > > menuconfig for VHOST_RING and do something similar?
> > > > > > >
> > > > > > > Thanks
> > > > > > Sorry I don't understand. After this patch CONFIG_VHOST_DPN is just
> > > > > > an internal variable for the OABI fix. I kept it separate
> > > > > > so it's easy to revert for 5.8. Yes we could squash it into
> > > > > > VHOST directly but I don't see how that changes logic at all.
> > > > > Sorry for being unclear.
> > > > >
> > > > > I meant since it was enabled by default, "CONFIG_VHOST_DPN=y" will be left
> > > > > in the defconfigs.
> > > > But who cares?
> > > FYI, please seehttps://www.spinics.net/lists/kvm/msg212685.html
> > The complaint was not about the symbol IIUC. It was that we caused
> > everyone to build vhost unless they manually disabled it.
>
>
> There could be some misunderstanding here. I thought it's somehow similar: a
> CONFIG_VHOST_MENU=y will be left in the defconfigs even if CONFIG_VHOST is
> not set.
>
> Thanks
Hmm. So looking at Documentation/kbuild/kconfig-language.rst :
Things that merit "default y/m" include:
a) A new Kconfig option for something that used to always be built
should be "default y".
b) A new gatekeeping Kconfig option that hides/shows other Kconfig
options (but does not generate any code of its own), should be
"default y" so people will see those other options.
c) Sub-driver behavior or similar options for a driver that is
"default n". This allows you to provide sane defaults.
So it looks like VHOST_MENU is actually matching rule b).
So what's the problem we are trying to solve with this patch, exactly?
Geert could you clarify pls?
>
> >
^ permalink raw reply
* Re: [PATCH V2] vhost: do not enable VHOST_MENU by default
From: Michael S. Tsirkin @ 2020-04-17 9:01 UTC (permalink / raw)
To: Jason Wang
Cc: linux-s390, tsbogend, gor, kvm, linux-kernel, heiko.carstens,
linux-mips, virtualization, borntraeger, geert, netdev, paulus,
linuxppc-dev
In-Reply-To: <73843240-3040-655d-baa9-683341ed4786@redhat.com>
On Fri, Apr 17, 2020 at 04:51:19PM +0800, Jason Wang wrote:
>
> On 2020/4/17 下午4:46, Michael S. Tsirkin wrote:
> > On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote:
> > > On 2020/4/17 下午4:29, Michael S. Tsirkin wrote:
> > > > On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:
> > > > > On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:
> > > > > > On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:
> > > > > > > On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:
> > > > > > > > On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote:
> > > > > > > > > We try to keep the defconfig untouched after decoupling CONFIG_VHOST
> > > > > > > > > out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
> > > > > > > > > ("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
> > > > > > > > > default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
> > > > > > > > > without the caring of CONFIG_VHOST.
> > > > > > > > >
> > > > > > > > > But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
> > > > > > > > > for the ones that doesn't want vhost. So it actually shifts the
> > > > > > > > > burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
> > > > > > > > > not set". So this patch tries to enable CONFIG_VHOST explicitly in
> > > > > > > > > defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.
> > > > > > > > >
> > > > > > > > > Acked-by: Christian Borntraeger<borntraeger@de.ibm.com> (s390)
> > > > > > > > > Acked-by: Michael Ellerman<mpe@ellerman.id.au> (powerpc)
> > > > > > > > > Cc: Thomas Bogendoerfer<tsbogend@alpha.franken.de>
> > > > > > > > > Cc: Benjamin Herrenschmidt<benh@kernel.crashing.org>
> > > > > > > > > Cc: Paul Mackerras<paulus@samba.org>
> > > > > > > > > Cc: Michael Ellerman<mpe@ellerman.id.au>
> > > > > > > > > Cc: Heiko Carstens<heiko.carstens@de.ibm.com>
> > > > > > > > > Cc: Vasily Gorbik<gor@linux.ibm.com>
> > > > > > > > > Cc: Christian Borntraeger<borntraeger@de.ibm.com>
> > > > > > > > > Reported-by: Geert Uytterhoeven<geert@linux-m68k.org>
> > > > > > > > > Signed-off-by: Jason Wang<jasowang@redhat.com>
> > > > > > > > I rebased this on top of OABI fix since that
> > > > > > > > seems more orgent to fix.
> > > > > > > > Pushed to my vhost branch pls take a look and
> > > > > > > > if possible test.
> > > > > > > > Thanks!
> > > > > > > I test this patch by generating the defconfigs that wants vhost_net or
> > > > > > > vhost_vsock. All looks fine.
> > > > > > >
> > > > > > > But having CONFIG_VHOST_DPN=y may end up with the similar situation that
> > > > > > > this patch want to address.
> > > > > > > Maybe we can let CONFIG_VHOST depends on !ARM || AEABI then add another
> > > > > > > menuconfig for VHOST_RING and do something similar?
> > > > > > >
> > > > > > > Thanks
> > > > > > Sorry I don't understand. After this patch CONFIG_VHOST_DPN is just
> > > > > > an internal variable for the OABI fix. I kept it separate
> > > > > > so it's easy to revert for 5.8. Yes we could squash it into
> > > > > > VHOST directly but I don't see how that changes logic at all.
> > > > > Sorry for being unclear.
> > > > >
> > > > > I meant since it was enabled by default, "CONFIG_VHOST_DPN=y" will be left
> > > > > in the defconfigs.
> > > > But who cares?
> > > FYI, please seehttps://www.spinics.net/lists/kvm/msg212685.html
> > The complaint was not about the symbol IIUC. It was that we caused
> > everyone to build vhost unless they manually disabled it.
>
>
> There could be some misunderstanding here. I thought it's somehow similar: a
> CONFIG_VHOST_MENU=y will be left in the defconfigs even if CONFIG_VHOST is
> not set.
>
> Thanks
>
BTW do entries with no prompt actually appear in defconfig?
> >
^ permalink raw reply
* [PATCH v6 1/9] powerpc/vas: Initialize window attributes for GZIP coprocessor type
From: Haren Myneni @ 2020-04-17 9:00 UTC (permalink / raw)
To: mpe; +Cc: mikey, herbert, npiggin, linux-crypto, sukadev, linuxppc-dev, dja
In-Reply-To: <1587113732.2275.1096.camel@hbabu-laptop>
Initialize send and receive window attributes for GZIP high and
normal priority types.
Signed-off-by: Haren Myneni <haren@linux.ibm.com>
---
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 d62787f..52844a1 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -817,7 +817,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;
@@ -892,7 +893,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;
@@ -976,9 +978,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
^ permalink raw reply related
* [PATCH v6 2/9] powerpc/vas: Define VAS_TX_WIN_OPEN ioctl API
From: Haren Myneni @ 2020-04-17 9:01 UTC (permalink / raw)
To: mpe; +Cc: mikey, herbert, npiggin, linux-crypto, sukadev, linuxppc-dev, dja
In-Reply-To: <1587113732.2275.1096.camel@hbabu-laptop>
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 <haren@linux.ibm.com>
---
Documentation/userspace-api/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/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
index f759eda..f18accb 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -286,6 +286,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.h VAS API
'v' C0-FF linux/meye.h conflict!
'w' all CERN 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 0000000..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 <asm/ioctl.h>
+
+#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
^ permalink raw reply related
* [PATCH v6 3/9] powerpc/vas: Add VAS user space API
From: Haren Myneni @ 2020-04-17 9:02 UTC (permalink / raw)
To: mpe; +Cc: mikey, herbert, npiggin, linux-crypto, sukadev, linuxppc-dev, dja
In-Reply-To: <1587113732.2275.1096.camel@hbabu-laptop>
On power9, userspace can send GZIP compression requests directly to NX
once kernel establishes NX channel / window with VAS. This patch provides
user space API which allows user space to establish channel using 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, VAS_TX_WIN_OPEN icoctl to
open a window on specific VAS instance, 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().
Only NX GZIP coprocessor type is supported right now and allow GZIP
engine access via /dev/crypto/nx-gzip device node.
Thanks to Michael Ellerman for his changes and suggestions to make the
ioctl generic to support any coprocessor type.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Haren Myneni <haren@linux.ibm.com>
---
arch/powerpc/include/asm/vas.h | 12 ++
arch/powerpc/platforms/powernv/Makefile | 2 +-
arch/powerpc/platforms/powernv/vas-api.c | 278 ++++++++++++++++++++++++++++
arch/powerpc/platforms/powernv/vas-window.c | 6 +-
arch/powerpc/platforms/powernv/vas.h | 2 +
5 files changed, 296 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/platforms/powernv/vas-api.c
diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h
index f93e6b0..6e427bc 100644
--- a/arch/powerpc/include/asm/vas.h
+++ b/arch/powerpc/include/asm/vas.h
@@ -163,4 +163,16 @@ 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);
+/*
+ * Register / unregister coprocessor type to VAS API which will be exported
+ * to user space. Applications can use this API to open / close window
+ * which can be used to send / receive requests directly to cooprcessor.
+ *
+ * Only NX GZIP coprocessor type is supported now, but this API can be
+ * used for others in future.
+ */
+int vas_register_coproc_api(struct module *mod, enum vas_cop_type cop_type,
+ const char *name);
+void vas_unregister_coproc_api(void);
+
#endif /* __ASM_POWERPC_VAS_H */
diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
index 395789f..fe3f0fb 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -17,7 +17,7 @@ obj-$(CONFIG_MEMORY_FAILURE) += opal-memory-errors.o
obj-$(CONFIG_OPAL_PRD) += opal-prd.o
obj-$(CONFIG_PERF_EVENTS) += opal-imc.o
obj-$(CONFIG_PPC_MEMTRACE) += memtrace.o
-obj-$(CONFIG_PPC_VAS) += vas.o vas-window.o vas-debug.o vas-fault.o
+obj-$(CONFIG_PPC_VAS) += vas.o vas-window.o vas-debug.o vas-fault.o vas-api.o
obj-$(CONFIG_OCXL_BASE) += ocxl.o
obj-$(CONFIG_SCOM_DEBUGFS) += opal-xscom.o
obj-$(CONFIG_PPC_SECURE_BOOT) += opal-secvar.o
diff --git a/arch/powerpc/platforms/powernv/vas-api.c b/arch/powerpc/platforms/powernv/vas-api.c
new file mode 100644
index 0000000..98ed5d8
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/vas-api.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * VAS user space API for its accelerators (Only NX-GZIP is supported now)
+ * Copyright (C) 2019 Haren Myneni, IBM Corp
+ */
+
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/cdev.h>
+#include <linux/fs.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <asm/vas.h>
+#include <uapi/asm/vas-api.h>
+#include "vas.h"
+
+/*
+ * The driver creates the device node that can be used as follows:
+ * For NX-GZIP
+ *
+ * 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/paste returns to the user space directly. So refer NX hardware
+ * documententation for exact copy/paste usage and completion / error
+ * conditions.
+ */
+
+/*
+ * Wrapper object for the nx-gzip device - there is just one instance of
+ * this node for the whole system.
+ */
+static struct coproc_dev {
+ struct cdev cdev;
+ struct device *device;
+ char *name;
+ dev_t devt;
+ struct class *class;
+ enum vas_cop_type cop_type;
+} coproc_device;
+
+struct coproc_instance {
+ struct coproc_dev *coproc;
+ struct vas_window *txwin;
+};
+
+static char *coproc_devnode(struct device *dev, umode_t *mode)
+{
+ return kasprintf(GFP_KERNEL, "crypto/%s", dev_name(dev));
+}
+
+static int coproc_open(struct inode *inode, struct file *fp)
+{
+ struct coproc_instance *cp_inst;
+
+ cp_inst = kzalloc(sizeof(*cp_inst), GFP_KERNEL);
+ if (!cp_inst)
+ return -ENOMEM;
+
+ cp_inst->coproc = container_of(inode->i_cdev, struct coproc_dev,
+ cdev);
+ fp->private_data = cp_inst;
+
+ return 0;
+}
+
+static int coproc_ioc_tx_win_open(struct file *fp, unsigned long arg)
+{
+ void __user *uptr = (void __user *)arg;
+ struct vas_tx_win_attr txattr = {};
+ struct vas_tx_win_open_attr uattr;
+ struct coproc_instance *cp_inst;
+ struct vas_window *txwin;
+ int rc, vasid;
+
+ cp_inst = fp->private_data;
+
+ /*
+ * One window for file descriptor
+ */
+ if (cp_inst->txwin)
+ return -EEXIST;
+
+ rc = copy_from_user(&uattr, uptr, sizeof(uattr));
+ if (rc) {
+ pr_err("%s(): copy_from_user() returns %d\n", __func__, rc);
+ return -EFAULT;
+ }
+
+ if (uattr.version != 1) {
+ pr_err("Invalid version\n");
+ return -EINVAL;
+ }
+
+ vasid = uattr.vas_id;
+
+ vas_init_tx_win_attr(&txattr, cp_inst->coproc->cop_type);
+
+ txattr.lpid = mfspr(SPRN_LPID);
+ txattr.pidr = mfspr(SPRN_PID);
+ txattr.user_win = true;
+ txattr.rsvd_txbuf_count = false;
+ txattr.pswid = false;
+
+ pr_devel("Pid %d: Opening txwin, PIDR %ld\n", txattr.pidr,
+ mfspr(SPRN_PID));
+
+ txwin = vas_tx_win_open(vasid, cp_inst->coproc->cop_type, &txattr);
+ if (IS_ERR(txwin)) {
+ pr_err("%s() vas_tx_win_open() failed, %ld\n", __func__,
+ PTR_ERR(txwin));
+ return PTR_ERR(txwin);
+ }
+
+ cp_inst->txwin = txwin;
+
+ return 0;
+}
+
+static int coproc_release(struct inode *inode, struct file *fp)
+{
+ struct coproc_instance *cp_inst = fp->private_data;
+
+ if (cp_inst->txwin) {
+ vas_win_close(cp_inst->txwin);
+ cp_inst->txwin = NULL;
+ }
+
+ kfree(cp_inst);
+ fp->private_data = NULL;
+
+ /*
+ * We don't know here if user has other receive windows
+ * open, so we can't really call clear_thread_tidr().
+ * So, once the process calls set_thread_tidr(), the
+ * TIDR value sticks around until process exits, resulting
+ * in an extra copy in restore_sprs().
+ */
+
+ return 0;
+}
+
+static int coproc_mmap(struct file *fp, struct vm_area_struct *vma)
+{
+ struct coproc_instance *cp_inst = fp->private_data;
+ struct vas_window *txwin;
+ unsigned long pfn;
+ u64 paste_addr;
+ pgprot_t prot;
+ int rc;
+
+ txwin = cp_inst->txwin;
+
+ if ((vma->vm_end - vma->vm_start) > PAGE_SIZE) {
+ pr_debug("%s(): size 0x%zx, PAGE_SIZE 0x%zx\n", __func__,
+ (vma->vm_end - vma->vm_start), PAGE_SIZE);
+ return -EINVAL;
+ }
+
+ /* Ensure instance has an open send window */
+ if (!txwin) {
+ pr_err("%s(): No send window open?\n", __func__);
+ return -EINVAL;
+ }
+
+ vas_win_paste_addr(txwin, &paste_addr, NULL);
+ pfn = paste_addr >> PAGE_SHIFT;
+
+ /* flags, page_prot from cxl_mmap(), except we want cachable */
+ vma->vm_flags |= VM_IO | VM_PFNMAP;
+ vma->vm_page_prot = pgprot_cached(vma->vm_page_prot);
+
+ prot = __pgprot(pgprot_val(vma->vm_page_prot) | _PAGE_DIRTY);
+
+ rc = remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
+ vma->vm_end - vma->vm_start, prot);
+
+ pr_devel("%s(): paste addr %llx at %lx, rc %d\n", __func__,
+ paste_addr, vma->vm_start, rc);
+
+ return rc;
+}
+
+static long coproc_ioctl(struct file *fp, unsigned int cmd, unsigned long arg)
+{
+ switch (cmd) {
+ case VAS_TX_WIN_OPEN:
+ return coproc_ioc_tx_win_open(fp, arg);
+ default:
+ return -EINVAL;
+ }
+}
+
+static struct file_operations coproc_fops = {
+ .open = coproc_open,
+ .release = coproc_release,
+ .mmap = coproc_mmap,
+ .unlocked_ioctl = coproc_ioctl,
+};
+
+/*
+ * Supporting only nx-gzip coprocessor type now, but this API code
+ * extended to other coprocessor types later.
+ */
+int vas_register_coproc_api(struct module *mod, enum vas_cop_type cop_type,
+ const char *name)
+{
+ int rc = -EINVAL;
+ dev_t devno;
+
+ rc = alloc_chrdev_region(&coproc_device.devt, 1, 1, name);
+ if (rc) {
+ pr_err("Unable to allocate coproc major number: %i\n", rc);
+ return rc;
+ }
+
+ pr_devel("%s device allocated, dev [%i,%i]\n", name,
+ MAJOR(coproc_device.devt), MINOR(coproc_device.devt));
+
+ coproc_device.class = class_create(mod, name);
+ if (IS_ERR(coproc_device.class)) {
+ rc = PTR_ERR(coproc_device.class);
+ pr_err("Unable to create %s class %d\n", name, rc);
+ goto err_class;
+ }
+ coproc_device.class->devnode = coproc_devnode;
+ coproc_device.cop_type = cop_type;
+
+ coproc_fops.owner = mod;
+ cdev_init(&coproc_device.cdev, &coproc_fops);
+
+ devno = MKDEV(MAJOR(coproc_device.devt), 0);
+ rc = cdev_add(&coproc_device.cdev, devno, 1);
+ if (rc) {
+ pr_err("cdev_add() failed %d\n", rc);
+ goto err_cdev;
+ }
+
+ coproc_device.device = device_create(coproc_device.class, NULL,
+ devno, NULL, name, MINOR(devno));
+ if (IS_ERR(coproc_device.device)) {
+ rc = PTR_ERR(coproc_device.device);
+ pr_err("Unable to create coproc-%d %d\n", MINOR(devno), rc);
+ goto err;
+ }
+
+ pr_devel("%s: Added dev [%d,%d]\n", __func__, MAJOR(devno),
+ MINOR(devno));
+
+ return 0;
+
+err:
+ cdev_del(&coproc_device.cdev);
+err_cdev:
+ class_destroy(coproc_device.class);
+err_class:
+ unregister_chrdev_region(coproc_device.devt, 1);
+ return rc;
+}
+EXPORT_SYMBOL_GPL(vas_register_coproc_api);
+
+void vas_unregister_coproc_api(void)
+{
+ dev_t devno;
+
+ cdev_del(&coproc_device.cdev);
+ devno = MKDEV(MAJOR(coproc_device.devt), 0);
+ device_destroy(coproc_device.class, devno);
+
+ class_destroy(coproc_device.class);
+ unregister_chrdev_region(coproc_device.devt, 1);
+}
+EXPORT_SYMBOL_GPL(vas_unregister_coproc_api);
diff --git a/arch/powerpc/platforms/powernv/vas-window.c b/arch/powerpc/platforms/powernv/vas-window.c
index 52844a1..6434f9c 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -26,7 +26,7 @@
* Compute the paste address region for the window @window using the
* ->paste_base_addr and ->paste_win_id_shift we got from device tree.
*/
-static void compute_paste_address(struct vas_window *window, u64 *addr, int *len)
+void vas_win_paste_addr(struct vas_window *window, u64 *addr, int *len)
{
int winid;
u64 base, shift;
@@ -80,7 +80,7 @@ static void *map_paste_region(struct vas_window *txwin)
goto free_name;
txwin->paste_addr_name = name;
- compute_paste_address(txwin, &start, &len);
+ vas_win_paste_addr(txwin, &start, &len);
if (!request_mem_region(start, len, name)) {
pr_devel("%s(): request_mem_region(0x%llx, %d) failed\n",
@@ -138,7 +138,7 @@ static void unmap_paste_region(struct vas_window *window)
u64 busaddr_start;
if (window->paste_kaddr) {
- compute_paste_address(window, &busaddr_start, &len);
+ vas_win_paste_addr(window, &busaddr_start, &len);
unmap_region(window->paste_kaddr, busaddr_start, len);
window->paste_kaddr = NULL;
kfree(window->paste_addr_name);
diff --git a/arch/powerpc/platforms/powernv/vas.h b/arch/powerpc/platforms/powernv/vas.h
index a7143b1..70f793e 100644
--- a/arch/powerpc/platforms/powernv/vas.h
+++ b/arch/powerpc/platforms/powernv/vas.h
@@ -437,6 +437,8 @@ struct vas_winctx {
extern void vas_return_credit(struct vas_window *window, bool tx);
extern struct vas_window *vas_pswid_to_window(struct vas_instance *vinst,
uint32_t pswid);
+extern void vas_win_paste_addr(struct vas_window *window, u64 *addr,
+ int *len);
static inline int vas_window_pid(struct vas_window *window)
{
--
1.8.3.1
^ permalink raw reply related
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