* [PATCH v4 1/4] VFIO: platform: add reset struct and lookup table
2015-06-15 9:09 [PATCH v4 0/4] VFIO platform reset Eric Auger
@ 2015-06-15 9:09 ` Eric Auger
2015-06-15 9:09 ` [PATCH v4 2/4] VFIO: platform: add reset callback Eric Auger
` (4 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: Eric Auger @ 2015-06-15 9:09 UTC (permalink / raw)
To: linux-arm-kernel
This patch introduces the vfio_platform_reset_combo struct that
stores all the information useful to handle the reset modality:
compat string, name of the reset function, name of the module that
implements the reset function. A lookup table of such structures
is added, currently void.
Signed-off-by: Eric Auger <eric.auger@linaro.org>
---
v3 -> v4:
- update the commit message
v2 -> v3:
- add const in struct vfio_platform_reset_combo
- remove enum vfio_platform_reset_type
v2: creation
---
drivers/vfio/platform/vfio_platform_common.c | 3 +++
drivers/vfio/platform/vfio_platform_private.h | 6 ++++++
2 files changed, 9 insertions(+)
diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c
index abcff7a..611597e 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -25,6 +25,9 @@
static DEFINE_MUTEX(driver_lock);
+static const struct vfio_platform_reset_combo reset_lookup_table[] = {
+};
+
static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
{
int cnt = 0, i;
diff --git a/drivers/vfio/platform/vfio_platform_private.h b/drivers/vfio/platform/vfio_platform_private.h
index 5d31e04..9e37b9f 100644
--- a/drivers/vfio/platform/vfio_platform_private.h
+++ b/drivers/vfio/platform/vfio_platform_private.h
@@ -69,6 +69,12 @@ struct vfio_platform_device {
int (*get_irq)(struct vfio_platform_device *vdev, int i);
};
+struct vfio_platform_reset_combo {
+ const char *compat;
+ const char *reset_function_name;
+ const char *module_name;
+};
+
extern int vfio_platform_probe_common(struct vfio_platform_device *vdev,
struct device *dev);
extern struct vfio_platform_device *vfio_platform_remove_common
--
1.9.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v4 2/4] VFIO: platform: add reset callback
2015-06-15 9:09 [PATCH v4 0/4] VFIO platform reset Eric Auger
2015-06-15 9:09 ` [PATCH v4 1/4] VFIO: platform: add reset struct and lookup table Eric Auger
@ 2015-06-15 9:09 ` Eric Auger
2015-06-15 9:09 ` [PATCH v4 3/4] VFIO: platform: populate the reset function on probe Eric Auger
` (3 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: Eric Auger @ 2015-06-15 9:09 UTC (permalink / raw)
To: linux-arm-kernel
A new reset callback is introduced. If this callback is populated,
the reset is invoked on device first open/last close or upon userspace
ioctl. The modality is exposed on VFIO_DEVICE_GET_INFO.
Signed-off-by: Eric Auger <eric.auger@linaro.org>
---
v1 -> v2:
- reset now is also called on first open on top of last close
- remove IS_ERR_OR_NULL
---
drivers/vfio/platform/vfio_platform_common.c | 15 +++++++++++++--
drivers/vfio/platform/vfio_platform_private.h | 1 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c
index 611597e..6393581 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -103,6 +103,8 @@ static void vfio_platform_release(void *device_data)
mutex_lock(&driver_lock);
if (!(--vdev->refcnt)) {
+ if (vdev->reset)
+ vdev->reset(vdev);
vfio_platform_regions_cleanup(vdev);
vfio_platform_irq_cleanup(vdev);
}
@@ -130,6 +132,9 @@ static int vfio_platform_open(void *device_data)
ret = vfio_platform_irq_init(vdev);
if (ret)
goto err_irq;
+
+ if (vdev->reset)
+ vdev->reset(vdev);
}
vdev->refcnt++;
@@ -162,6 +167,8 @@ static long vfio_platform_ioctl(void *device_data,
if (info.argsz < minsz)
return -EINVAL;
+ if (vdev->reset)
+ vdev->flags |= VFIO_DEVICE_FLAGS_RESET;
info.flags = vdev->flags;
info.num_regions = vdev->num_regions;
info.num_irqs = vdev->num_irqs;
@@ -255,8 +262,12 @@ static long vfio_platform_ioctl(void *device_data,
return ret;
- } else if (cmd == VFIO_DEVICE_RESET)
- return -EINVAL;
+ } else if (cmd == VFIO_DEVICE_RESET) {
+ if (vdev->reset)
+ return vdev->reset(vdev);
+ else
+ return -EINVAL;
+ }
return -ENOTTY;
}
diff --git a/drivers/vfio/platform/vfio_platform_private.h b/drivers/vfio/platform/vfio_platform_private.h
index 9e37b9f..1c9b3d5 100644
--- a/drivers/vfio/platform/vfio_platform_private.h
+++ b/drivers/vfio/platform/vfio_platform_private.h
@@ -67,6 +67,7 @@ struct vfio_platform_device {
struct resource*
(*get_resource)(struct vfio_platform_device *vdev, int i);
int (*get_irq)(struct vfio_platform_device *vdev, int i);
+ int (*reset)(struct vfio_platform_device *vdev);
};
struct vfio_platform_reset_combo {
--
1.9.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v4 3/4] VFIO: platform: populate the reset function on probe
2015-06-15 9:09 [PATCH v4 0/4] VFIO platform reset Eric Auger
2015-06-15 9:09 ` [PATCH v4 1/4] VFIO: platform: add reset struct and lookup table Eric Auger
2015-06-15 9:09 ` [PATCH v4 2/4] VFIO: platform: add reset callback Eric Auger
@ 2015-06-15 9:09 ` Eric Auger
2015-06-15 9:09 ` [PATCH v4 4/4] VFIO: platform: Calxeda xgmac reset module Eric Auger
` (2 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: Eric Auger @ 2015-06-15 9:09 UTC (permalink / raw)
To: linux-arm-kernel
The reset function lookup happens on vfio-platform probe. The reset
module load is requested and a reference to the function symbol is
hold. The reference is released on vfio-platform remove.
Signed-off-by: Eric Auger <eric.auger@linaro.org>
---
v2 -> v3:
- vfio_platform_get_reset becomes void
- use ARRAY_SIZE
- use symbol_put_addr
v1 -> v2:
- [get,put]_reset now is called once on probe/remove
- use request_module to automatically load the reset module that
matches the compatibility string
- lookup table is used instead of list
- remove registration mechanism: reset function name is stored in the
lookup table.
- use device_property_read_string instead of
device_property_read_string_array
---
drivers/vfio/platform/vfio_platform_common.c | 37 +++++++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c
index 6393581..f3391a9 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -28,6 +28,36 @@ static DEFINE_MUTEX(driver_lock);
static const struct vfio_platform_reset_combo reset_lookup_table[] = {
};
+static void vfio_platform_get_reset(struct vfio_platform_device *vdev,
+ struct device *dev)
+{
+ const char *compat;
+ int (*reset)(struct vfio_platform_device *);
+ int ret, i;
+
+ ret = device_property_read_string(dev, "compatible", &compat);
+ if (ret)
+ return;
+
+ for (i = 0 ; i < ARRAY_SIZE(reset_lookup_table); i++) {
+ if (!strcmp(reset_lookup_table[i].compat, compat)) {
+ request_module(reset_lookup_table[i].module_name);
+ reset = __symbol_get(
+ reset_lookup_table[i].reset_function_name);
+ if (reset) {
+ vdev->reset = reset;
+ return;
+ }
+ }
+ }
+}
+
+static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
+{
+ if (vdev->reset)
+ symbol_put_addr(vdev->reset);
+}
+
static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
{
int cnt = 0, i;
@@ -516,6 +546,8 @@ int vfio_platform_probe_common(struct vfio_platform_device *vdev,
return ret;
}
+ vfio_platform_get_reset(vdev, dev);
+
mutex_init(&vdev->igate);
return 0;
@@ -527,8 +559,11 @@ struct vfio_platform_device *vfio_platform_remove_common(struct device *dev)
struct vfio_platform_device *vdev;
vdev = vfio_del_group_dev(dev);
- if (vdev)
+
+ if (vdev) {
+ vfio_platform_put_reset(vdev);
iommu_group_put(dev->iommu_group);
+ }
return vdev;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v4 4/4] VFIO: platform: Calxeda xgmac reset module
2015-06-15 9:09 [PATCH v4 0/4] VFIO platform reset Eric Auger
` (2 preceding siblings ...)
2015-06-15 9:09 ` [PATCH v4 3/4] VFIO: platform: populate the reset function on probe Eric Auger
@ 2015-06-15 9:09 ` Eric Auger
2015-06-17 22:31 ` [PATCH v4 0/4] VFIO platform reset Alex Williamson
2015-08-27 11:56 ` Eric Auger
5 siblings, 0 replies; 13+ messages in thread
From: Eric Auger @ 2015-06-15 9:09 UTC (permalink / raw)
To: linux-arm-kernel
This patch introduces a module that registers and implements a basic
reset function for the Calxeda xgmac device. This latter basically disables
interrupts and stops DMA transfers.
The reset function code is inherited from the native calxeda xgmac driver.
Signed-off-by: Eric Auger <eric.auger@linaro.org>
---
v2 -> v3:
- remove void vfio_platform_calxedaxgmac_init and
vfio_platform_calxedaxgmac_exit
- no enum vfio_platform_reset_type type anymore
v1 -> v2:
- remove registration mechanism. The module mainly exports the reset
function. module_init and module_exit now are void.
---
drivers/vfio/platform/Kconfig | 2 +
drivers/vfio/platform/Makefile | 2 +
drivers/vfio/platform/reset/Kconfig | 7 ++
drivers/vfio/platform/reset/Makefile | 5 ++
.../platform/reset/vfio_platform_calxedaxgmac.c | 86 ++++++++++++++++++++++
drivers/vfio/platform/vfio_platform_common.c | 5 ++
6 files changed, 107 insertions(+)
create mode 100644 drivers/vfio/platform/reset/Kconfig
create mode 100644 drivers/vfio/platform/reset/Makefile
create mode 100644 drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig
index 9a4403e..1df7477 100644
--- a/drivers/vfio/platform/Kconfig
+++ b/drivers/vfio/platform/Kconfig
@@ -18,3 +18,5 @@ config VFIO_AMBA
framework.
If you don't know what to do here, say N.
+
+source "drivers/vfio/platform/reset/Kconfig"
diff --git a/drivers/vfio/platform/Makefile b/drivers/vfio/platform/Makefile
index 81de144..9ce8afe 100644
--- a/drivers/vfio/platform/Makefile
+++ b/drivers/vfio/platform/Makefile
@@ -2,7 +2,9 @@
vfio-platform-y := vfio_platform.o vfio_platform_common.o vfio_platform_irq.o
obj-$(CONFIG_VFIO_PLATFORM) += vfio-platform.o
+obj-$(CONFIG_VFIO_PLATFORM) += reset/
vfio-amba-y := vfio_amba.o
obj-$(CONFIG_VFIO_AMBA) += vfio-amba.o
+obj-$(CONFIG_VFIO_AMBA) += reset/
diff --git a/drivers/vfio/platform/reset/Kconfig b/drivers/vfio/platform/reset/Kconfig
new file mode 100644
index 0000000..746b96b
--- /dev/null
+++ b/drivers/vfio/platform/reset/Kconfig
@@ -0,0 +1,7 @@
+config VFIO_PLATFORM_CALXEDAXGMAC_RESET
+ tristate "VFIO support for calxeda xgmac reset"
+ depends on VFIO_PLATFORM
+ help
+ Enables the VFIO platform driver to handle reset for Calxeda xgmac
+
+ If you don't know what to do here, say N.
diff --git a/drivers/vfio/platform/reset/Makefile b/drivers/vfio/platform/reset/Makefile
new file mode 100644
index 0000000..2a486af
--- /dev/null
+++ b/drivers/vfio/platform/reset/Makefile
@@ -0,0 +1,5 @@
+vfio-platform-calxedaxgmac-y := vfio_platform_calxedaxgmac.o
+
+ccflags-y += -Idrivers/vfio/platform
+
+obj-$(CONFIG_VFIO_PLATFORM_CALXEDAXGMAC_RESET) += vfio-platform-calxedaxgmac.o
diff --git a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
new file mode 100644
index 0000000..619dc7d
--- /dev/null
+++ b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
@@ -0,0 +1,86 @@
+/*
+ * VFIO platform driver specialized for Calxeda xgmac reset
+ * reset code is inherited from calxeda xgmac native driver
+ *
+ * Copyright 2010-2011 Calxeda, Inc.
+ * Copyright (c) 2015 Linaro Ltd.
+ * www.linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/io.h>
+
+#include "vfio_platform_private.h"
+
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR "Eric Auger <eric.auger@linaro.org>"
+#define DRIVER_DESC "Reset support for Calxeda xgmac vfio platform device"
+
+#define CALXEDAXGMAC_COMPAT "calxeda,hb-xgmac"
+
+/* XGMAC Register definitions */
+#define XGMAC_CONTROL 0x00000000 /* MAC Configuration */
+
+/* DMA Control and Status Registers */
+#define XGMAC_DMA_CONTROL 0x00000f18 /* Ctrl (Operational Mode) */
+#define XGMAC_DMA_INTR_ENA 0x00000f1c /* Interrupt Enable */
+
+/* DMA Control registe defines */
+#define DMA_CONTROL_ST 0x00002000 /* Start/Stop Transmission */
+#define DMA_CONTROL_SR 0x00000002 /* Start/Stop Receive */
+
+/* Common MAC defines */
+#define MAC_ENABLE_TX 0x00000008 /* Transmitter Enable */
+#define MAC_ENABLE_RX 0x00000004 /* Receiver Enable */
+
+static inline void xgmac_mac_disable(void __iomem *ioaddr)
+{
+ u32 value = readl(ioaddr + XGMAC_DMA_CONTROL);
+
+ value &= ~(DMA_CONTROL_ST | DMA_CONTROL_SR);
+ writel(value, ioaddr + XGMAC_DMA_CONTROL);
+
+ value = readl(ioaddr + XGMAC_CONTROL);
+ value &= ~(MAC_ENABLE_TX | MAC_ENABLE_RX);
+ writel(value, ioaddr + XGMAC_CONTROL);
+}
+
+int vfio_platform_calxedaxgmac_reset(struct vfio_platform_device *vdev)
+{
+ struct vfio_platform_region reg = vdev->regions[0];
+
+ if (!reg.ioaddr) {
+ reg.ioaddr =
+ ioremap_nocache(reg.addr, reg.size);
+ if (!reg.ioaddr)
+ return -ENOMEM;
+ }
+
+ /* disable IRQ */
+ writel(0, reg.ioaddr + XGMAC_DMA_INTR_ENA);
+
+ /* Disable the MAC core */
+ xgmac_mac_disable(reg.ioaddr);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(vfio_platform_calxedaxgmac_reset);
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c
index f3391a9..e43efb5 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -26,6 +26,11 @@
static DEFINE_MUTEX(driver_lock);
static const struct vfio_platform_reset_combo reset_lookup_table[] = {
+ {
+ .compat = "calxeda,hb-xgmac",
+ .reset_function_name = "vfio_platform_calxedaxgmac_reset",
+ .module_name = "vfio-platform-calxedaxgmac",
+ },
};
static void vfio_platform_get_reset(struct vfio_platform_device *vdev,
--
1.9.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v4 0/4] VFIO platform reset
2015-06-15 9:09 [PATCH v4 0/4] VFIO platform reset Eric Auger
` (3 preceding siblings ...)
2015-06-15 9:09 ` [PATCH v4 4/4] VFIO: platform: Calxeda xgmac reset module Eric Auger
@ 2015-06-17 22:31 ` Alex Williamson
2015-06-18 15:23 ` Baptiste Reynal
2015-08-27 11:56 ` Eric Auger
5 siblings, 1 reply; 13+ messages in thread
From: Alex Williamson @ 2015-06-17 22:31 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2015-06-15 at 11:09 +0200, Eric Auger wrote:
> In situations where the userspace driver is stopped abnormally and the
> VFIO platform device is released, the assigned HW device currently is
> left running. As a consequence the HW device might continue issuing IRQs
> and performing DMA accesses.
>
> On release, no physical IRQ handler is setup anymore. Also the DMA buffers
> are unmapped leading to IOMMU aborts. So there is no serious consequence.
>
> However when assigning that HW device again to another userspace driver,
> this latter might face some unexpected IRQs and DMA accesses, which are
> the result of the previous assignment.
>
> In virtualization use-case, a VM newly granted with that HW device may be
> impacted by the assignment of that device to a previous VM:
> - IRQs may be injected very early when booting the new guest, even before
> the guest driver has initialized leading to possible driver state
> inconsistency.
> - DMA accesses may hit the newly mapped VM address space at addresses that
> may jeopardize the integrity of the newly installed VM.
>
> Obviously the criticity depends on the assigned HW device.
>
> As opposed to PCI, there is no standard mechanism to reset the platform
> device.
>
> This series proposes to implement device specific reset functions in
> separate in-kernel vfio reset modules. The vfio-platform driver holds
> a whitelist of implemented triplets (compat string, module name,
> reset function name). When the vfio-platform driver is probed it identifies
> the fellow reset module/function matching the compat string of the
> device, if any, and forces the load of this reset module.
>
> A first reset module is provided: the vfio-platform-calxedaxgmac
> module which implements a basic reset for the Calxeda xgmac.
>
> The series can be found at
> https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.1-rc8-reset-v4
>
> History:
> v3 -> v4:
> - fix the commit message of "VFIO: platform: add reset struct and lookup table"
Baptiste,
Any comments? Should we also add something like this to MAINTAINERS
before we go much further?
diff --git a/MAINTAINERS b/MAINTAINERS
index d8afd29..c6bf7f6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10545,6 +10545,12 @@ F: drivers/vfio/
F: include/linux/vfio.h
F: include/uapi/linux/vfio.h
+VFIO PLATFORM DRIVER
+M: Baptiste Reynal <b.reynal@virtualopensystems.com>
+L: kvm at vger.kernel.org
+S: Maintained
+F: drivers/vfio/platform/
+
VIDEOBUF2 FRAMEWORK
M: Pawel Osciak <pawel@osciak.com>
M: Marek Szyprowski <m.szyprowski@samsung.com>
I'm not sure what you want to be the primary list, maybe it's time to
ask for a vfio list. Thanks,
Alex
>
> v2 -> v3:
> - remove void module_init/exit functions in calxeda reset module
> - remove enum vfio_platform_reset_type
> - for reset lookup, use ARRAY_SIZE
> - in reset put use symbol_put_addr
>
> v1 -> v2:
> - much simplified compared to v1 although principle of external modules is
> kept: removed mechanism of dynamic registration of reset functions
> - list is replaced by whitelist lookup table
> - name of the reset function also stored in the lookup table
> - autoload of reset modules
>
> RFC -> PATCH v1:
> - solution now based on a lookup list instead of specialized driver
>
>
> Eric Auger (4):
> VFIO: platform: add reset struct and lookup table
> VFIO: platform: add reset callback
> VFIO: platform: populate the reset function on probe
> VFIO: platform: Calxeda xgmac reset module
>
> drivers/vfio/platform/Kconfig | 2 +
> drivers/vfio/platform/Makefile | 2 +
> drivers/vfio/platform/reset/Kconfig | 7 ++
> drivers/vfio/platform/reset/Makefile | 5 ++
> .../platform/reset/vfio_platform_calxedaxgmac.c | 86 ++++++++++++++++++++++
> drivers/vfio/platform/vfio_platform_common.c | 60 ++++++++++++++-
> drivers/vfio/platform/vfio_platform_private.h | 7 ++
> 7 files changed, 166 insertions(+), 3 deletions(-)
> create mode 100644 drivers/vfio/platform/reset/Kconfig
> create mode 100644 drivers/vfio/platform/reset/Makefile
> create mode 100644 drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
>
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v4 0/4] VFIO platform reset
2015-06-17 22:31 ` [PATCH v4 0/4] VFIO platform reset Alex Williamson
@ 2015-06-18 15:23 ` Baptiste Reynal
2015-06-18 16:17 ` Alex Williamson
0 siblings, 1 reply; 13+ messages in thread
From: Baptiste Reynal @ 2015-06-18 15:23 UTC (permalink / raw)
To: linux-arm-kernel
Hello everyone,
I tested and reviewed the patches, everything's fine for me.
I agree to be maintainer of vfio platform drivers, though I don't
think the volume of patches about VFIO will justify a new mailing
list.
Regards,
Baptiste
On Thu, Jun 18, 2015 at 12:31 AM, Alex Williamson
<alex.williamson@redhat.com> wrote:
> On Mon, 2015-06-15 at 11:09 +0200, Eric Auger wrote:
>> In situations where the userspace driver is stopped abnormally and the
>> VFIO platform device is released, the assigned HW device currently is
>> left running. As a consequence the HW device might continue issuing IRQs
>> and performing DMA accesses.
>>
>> On release, no physical IRQ handler is setup anymore. Also the DMA buffers
>> are unmapped leading to IOMMU aborts. So there is no serious consequence.
>>
>> However when assigning that HW device again to another userspace driver,
>> this latter might face some unexpected IRQs and DMA accesses, which are
>> the result of the previous assignment.
>>
>> In virtualization use-case, a VM newly granted with that HW device may be
>> impacted by the assignment of that device to a previous VM:
>> - IRQs may be injected very early when booting the new guest, even before
>> the guest driver has initialized leading to possible driver state
>> inconsistency.
>> - DMA accesses may hit the newly mapped VM address space at addresses that
>> may jeopardize the integrity of the newly installed VM.
>>
>> Obviously the criticity depends on the assigned HW device.
>>
>> As opposed to PCI, there is no standard mechanism to reset the platform
>> device.
>>
>> This series proposes to implement device specific reset functions in
>> separate in-kernel vfio reset modules. The vfio-platform driver holds
>> a whitelist of implemented triplets (compat string, module name,
>> reset function name). When the vfio-platform driver is probed it identifies
>> the fellow reset module/function matching the compat string of the
>> device, if any, and forces the load of this reset module.
>>
>> A first reset module is provided: the vfio-platform-calxedaxgmac
>> module which implements a basic reset for the Calxeda xgmac.
>>
>> The series can be found at
>> https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.1-rc8-reset-v4
>>
>> History:
>> v3 -> v4:
>> - fix the commit message of "VFIO: platform: add reset struct and lookup table"
>
> Baptiste,
>
> Any comments? Should we also add something like this to MAINTAINERS
> before we go much further?
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d8afd29..c6bf7f6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10545,6 +10545,12 @@ F: drivers/vfio/
> F: include/linux/vfio.h
> F: include/uapi/linux/vfio.h
>
> +VFIO PLATFORM DRIVER
> +M: Baptiste Reynal <b.reynal@virtualopensystems.com>
> +L: kvm at vger.kernel.org
> +S: Maintained
> +F: drivers/vfio/platform/
> +
> VIDEOBUF2 FRAMEWORK
> M: Pawel Osciak <pawel@osciak.com>
> M: Marek Szyprowski <m.szyprowski@samsung.com>
>
> I'm not sure what you want to be the primary list, maybe it's time to
> ask for a vfio list. Thanks,
> Alex
>
>>
>> v2 -> v3:
>> - remove void module_init/exit functions in calxeda reset module
>> - remove enum vfio_platform_reset_type
>> - for reset lookup, use ARRAY_SIZE
>> - in reset put use symbol_put_addr
>>
>> v1 -> v2:
>> - much simplified compared to v1 although principle of external modules is
>> kept: removed mechanism of dynamic registration of reset functions
>> - list is replaced by whitelist lookup table
>> - name of the reset function also stored in the lookup table
>> - autoload of reset modules
>>
>> RFC -> PATCH v1:
>> - solution now based on a lookup list instead of specialized driver
>>
>>
>> Eric Auger (4):
>> VFIO: platform: add reset struct and lookup table
>> VFIO: platform: add reset callback
>> VFIO: platform: populate the reset function on probe
>> VFIO: platform: Calxeda xgmac reset module
>>
>> drivers/vfio/platform/Kconfig | 2 +
>> drivers/vfio/platform/Makefile | 2 +
>> drivers/vfio/platform/reset/Kconfig | 7 ++
>> drivers/vfio/platform/reset/Makefile | 5 ++
>> .../platform/reset/vfio_platform_calxedaxgmac.c | 86 ++++++++++++++++++++++
>> drivers/vfio/platform/vfio_platform_common.c | 60 ++++++++++++++-
>> drivers/vfio/platform/vfio_platform_private.h | 7 ++
>> 7 files changed, 166 insertions(+), 3 deletions(-)
>> create mode 100644 drivers/vfio/platform/reset/Kconfig
>> create mode 100644 drivers/vfio/platform/reset/Makefile
>> create mode 100644 drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
>>
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v4 0/4] VFIO platform reset
2015-06-18 15:23 ` Baptiste Reynal
@ 2015-06-18 16:17 ` Alex Williamson
2015-06-19 7:53 ` Baptiste Reynal
0 siblings, 1 reply; 13+ messages in thread
From: Alex Williamson @ 2015-06-18 16:17 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 2015-06-18 at 17:23 +0200, Baptiste Reynal wrote:
> Hello everyone,
>
> I tested and reviewed the patches, everything's fine for me.
Hi Baptiste,
Would you like to provide a Sign-off/Ack/Review tag for the series then?
> I agree to be maintainer of vfio platform drivers, though I don't
> think the volume of patches about VFIO will justify a new mailing
> list.
Ok, I'll officially post the patch for MAINTAINERS then. Until someone
complains, we'll continue to use the kvm list. Thanks,
Alex
> On Thu, Jun 18, 2015 at 12:31 AM, Alex Williamson
> <alex.williamson@redhat.com> wrote:
> > On Mon, 2015-06-15 at 11:09 +0200, Eric Auger wrote:
> >> In situations where the userspace driver is stopped abnormally and the
> >> VFIO platform device is released, the assigned HW device currently is
> >> left running. As a consequence the HW device might continue issuing IRQs
> >> and performing DMA accesses.
> >>
> >> On release, no physical IRQ handler is setup anymore. Also the DMA buffers
> >> are unmapped leading to IOMMU aborts. So there is no serious consequence.
> >>
> >> However when assigning that HW device again to another userspace driver,
> >> this latter might face some unexpected IRQs and DMA accesses, which are
> >> the result of the previous assignment.
> >>
> >> In virtualization use-case, a VM newly granted with that HW device may be
> >> impacted by the assignment of that device to a previous VM:
> >> - IRQs may be injected very early when booting the new guest, even before
> >> the guest driver has initialized leading to possible driver state
> >> inconsistency.
> >> - DMA accesses may hit the newly mapped VM address space at addresses that
> >> may jeopardize the integrity of the newly installed VM.
> >>
> >> Obviously the criticity depends on the assigned HW device.
> >>
> >> As opposed to PCI, there is no standard mechanism to reset the platform
> >> device.
> >>
> >> This series proposes to implement device specific reset functions in
> >> separate in-kernel vfio reset modules. The vfio-platform driver holds
> >> a whitelist of implemented triplets (compat string, module name,
> >> reset function name). When the vfio-platform driver is probed it identifies
> >> the fellow reset module/function matching the compat string of the
> >> device, if any, and forces the load of this reset module.
> >>
> >> A first reset module is provided: the vfio-platform-calxedaxgmac
> >> module which implements a basic reset for the Calxeda xgmac.
> >>
> >> The series can be found at
> >> https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.1-rc8-reset-v4
> >>
> >> History:
> >> v3 -> v4:
> >> - fix the commit message of "VFIO: platform: add reset struct and lookup table"
> >
> > Baptiste,
> >
> > Any comments? Should we also add something like this to MAINTAINERS
> > before we go much further?
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index d8afd29..c6bf7f6 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -10545,6 +10545,12 @@ F: drivers/vfio/
> > F: include/linux/vfio.h
> > F: include/uapi/linux/vfio.h
> >
> > +VFIO PLATFORM DRIVER
> > +M: Baptiste Reynal <b.reynal@virtualopensystems.com>
> > +L: kvm at vger.kernel.org
> > +S: Maintained
> > +F: drivers/vfio/platform/
> > +
> > VIDEOBUF2 FRAMEWORK
> > M: Pawel Osciak <pawel@osciak.com>
> > M: Marek Szyprowski <m.szyprowski@samsung.com>
> >
> > I'm not sure what you want to be the primary list, maybe it's time to
> > ask for a vfio list. Thanks,
> > Alex
> >
> >>
> >> v2 -> v3:
> >> - remove void module_init/exit functions in calxeda reset module
> >> - remove enum vfio_platform_reset_type
> >> - for reset lookup, use ARRAY_SIZE
> >> - in reset put use symbol_put_addr
> >>
> >> v1 -> v2:
> >> - much simplified compared to v1 although principle of external modules is
> >> kept: removed mechanism of dynamic registration of reset functions
> >> - list is replaced by whitelist lookup table
> >> - name of the reset function also stored in the lookup table
> >> - autoload of reset modules
> >>
> >> RFC -> PATCH v1:
> >> - solution now based on a lookup list instead of specialized driver
> >>
> >>
> >> Eric Auger (4):
> >> VFIO: platform: add reset struct and lookup table
> >> VFIO: platform: add reset callback
> >> VFIO: platform: populate the reset function on probe
> >> VFIO: platform: Calxeda xgmac reset module
> >>
> >> drivers/vfio/platform/Kconfig | 2 +
> >> drivers/vfio/platform/Makefile | 2 +
> >> drivers/vfio/platform/reset/Kconfig | 7 ++
> >> drivers/vfio/platform/reset/Makefile | 5 ++
> >> .../platform/reset/vfio_platform_calxedaxgmac.c | 86 ++++++++++++++++++++++
> >> drivers/vfio/platform/vfio_platform_common.c | 60 ++++++++++++++-
> >> drivers/vfio/platform/vfio_platform_private.h | 7 ++
> >> 7 files changed, 166 insertions(+), 3 deletions(-)
> >> create mode 100644 drivers/vfio/platform/reset/Kconfig
> >> create mode 100644 drivers/vfio/platform/reset/Makefile
> >> create mode 100644 drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
> >>
> >
> >
> >
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v4 0/4] VFIO platform reset
2015-06-18 16:17 ` Alex Williamson
@ 2015-06-19 7:53 ` Baptiste Reynal
2015-06-22 7:58 ` Eric Auger
2015-06-22 15:43 ` Alex Williamson
0 siblings, 2 replies; 13+ messages in thread
From: Baptiste Reynal @ 2015-06-19 7:53 UTC (permalink / raw)
To: linux-arm-kernel
[1-4/4]
Acked-by: Baptiste Reynal <b.reynal@virtualopensystems.com>
Tested-by: Baptiste Reynal <b.reynal@virtualopensystems.com>
Reviewed-by: Baptiste Reynal <b.reynal@virtualopensystems.com>
On Thu, Jun 18, 2015 at 6:17 PM, Alex Williamson
<alex.williamson@redhat.com> wrote:
> On Thu, 2015-06-18 at 17:23 +0200, Baptiste Reynal wrote:
>> Hello everyone,
>>
>> I tested and reviewed the patches, everything's fine for me.
>
> Hi Baptiste,
>
> Would you like to provide a Sign-off/Ack/Review tag for the series then?
>
>> I agree to be maintainer of vfio platform drivers, though I don't
>> think the volume of patches about VFIO will justify a new mailing
>> list.
>
> Ok, I'll officially post the patch for MAINTAINERS then. Until someone
> complains, we'll continue to use the kvm list. Thanks,
>
> Alex
>
>> On Thu, Jun 18, 2015 at 12:31 AM, Alex Williamson
>> <alex.williamson@redhat.com> wrote:
>> > On Mon, 2015-06-15 at 11:09 +0200, Eric Auger wrote:
>> >> In situations where the userspace driver is stopped abnormally and the
>> >> VFIO platform device is released, the assigned HW device currently is
>> >> left running. As a consequence the HW device might continue issuing IRQs
>> >> and performing DMA accesses.
>> >>
>> >> On release, no physical IRQ handler is setup anymore. Also the DMA buffers
>> >> are unmapped leading to IOMMU aborts. So there is no serious consequence.
>> >>
>> >> However when assigning that HW device again to another userspace driver,
>> >> this latter might face some unexpected IRQs and DMA accesses, which are
>> >> the result of the previous assignment.
>> >>
>> >> In virtualization use-case, a VM newly granted with that HW device may be
>> >> impacted by the assignment of that device to a previous VM:
>> >> - IRQs may be injected very early when booting the new guest, even before
>> >> the guest driver has initialized leading to possible driver state
>> >> inconsistency.
>> >> - DMA accesses may hit the newly mapped VM address space at addresses that
>> >> may jeopardize the integrity of the newly installed VM.
>> >>
>> >> Obviously the criticity depends on the assigned HW device.
>> >>
>> >> As opposed to PCI, there is no standard mechanism to reset the platform
>> >> device.
>> >>
>> >> This series proposes to implement device specific reset functions in
>> >> separate in-kernel vfio reset modules. The vfio-platform driver holds
>> >> a whitelist of implemented triplets (compat string, module name,
>> >> reset function name). When the vfio-platform driver is probed it identifies
>> >> the fellow reset module/function matching the compat string of the
>> >> device, if any, and forces the load of this reset module.
>> >>
>> >> A first reset module is provided: the vfio-platform-calxedaxgmac
>> >> module which implements a basic reset for the Calxeda xgmac.
>> >>
>> >> The series can be found at
>> >> https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.1-rc8-reset-v4
>> >>
>> >> History:
>> >> v3 -> v4:
>> >> - fix the commit message of "VFIO: platform: add reset struct and lookup table"
>> >
>> > Baptiste,
>> >
>> > Any comments? Should we also add something like this to MAINTAINERS
>> > before we go much further?
>> >
>> > diff --git a/MAINTAINERS b/MAINTAINERS
>> > index d8afd29..c6bf7f6 100644
>> > --- a/MAINTAINERS
>> > +++ b/MAINTAINERS
>> > @@ -10545,6 +10545,12 @@ F: drivers/vfio/
>> > F: include/linux/vfio.h
>> > F: include/uapi/linux/vfio.h
>> >
>> > +VFIO PLATFORM DRIVER
>> > +M: Baptiste Reynal <b.reynal@virtualopensystems.com>
>> > +L: kvm at vger.kernel.org
>> > +S: Maintained
>> > +F: drivers/vfio/platform/
>> > +
>> > VIDEOBUF2 FRAMEWORK
>> > M: Pawel Osciak <pawel@osciak.com>
>> > M: Marek Szyprowski <m.szyprowski@samsung.com>
>> >
>> > I'm not sure what you want to be the primary list, maybe it's time to
>> > ask for a vfio list. Thanks,
>> > Alex
>> >
>> >>
>> >> v2 -> v3:
>> >> - remove void module_init/exit functions in calxeda reset module
>> >> - remove enum vfio_platform_reset_type
>> >> - for reset lookup, use ARRAY_SIZE
>> >> - in reset put use symbol_put_addr
>> >>
>> >> v1 -> v2:
>> >> - much simplified compared to v1 although principle of external modules is
>> >> kept: removed mechanism of dynamic registration of reset functions
>> >> - list is replaced by whitelist lookup table
>> >> - name of the reset function also stored in the lookup table
>> >> - autoload of reset modules
>> >>
>> >> RFC -> PATCH v1:
>> >> - solution now based on a lookup list instead of specialized driver
>> >>
>> >>
>> >> Eric Auger (4):
>> >> VFIO: platform: add reset struct and lookup table
>> >> VFIO: platform: add reset callback
>> >> VFIO: platform: populate the reset function on probe
>> >> VFIO: platform: Calxeda xgmac reset module
>> >>
>> >> drivers/vfio/platform/Kconfig | 2 +
>> >> drivers/vfio/platform/Makefile | 2 +
>> >> drivers/vfio/platform/reset/Kconfig | 7 ++
>> >> drivers/vfio/platform/reset/Makefile | 5 ++
>> >> .../platform/reset/vfio_platform_calxedaxgmac.c | 86 ++++++++++++++++++++++
>> >> drivers/vfio/platform/vfio_platform_common.c | 60 ++++++++++++++-
>> >> drivers/vfio/platform/vfio_platform_private.h | 7 ++
>> >> 7 files changed, 166 insertions(+), 3 deletions(-)
>> >> create mode 100644 drivers/vfio/platform/reset/Kconfig
>> >> create mode 100644 drivers/vfio/platform/reset/Makefile
>> >> create mode 100644 drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
>> >>
>> >
>> >
>> >
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v4 0/4] VFIO platform reset
2015-06-19 7:53 ` Baptiste Reynal
@ 2015-06-22 7:58 ` Eric Auger
2015-06-22 15:43 ` Alex Williamson
1 sibling, 0 replies; 13+ messages in thread
From: Eric Auger @ 2015-06-22 7:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi Baptiste,
On 06/19/2015 09:53 AM, Baptiste Reynal wrote:
> [1-4/4]
> Acked-by: Baptiste Reynal <b.reynal@virtualopensystems.com>
> Tested-by: Baptiste Reynal <b.reynal@virtualopensystems.com>
> Reviewed-by: Baptiste Reynal <b.reynal@virtualopensystems.com>
>
Thanks!
Eric
> On Thu, Jun 18, 2015 at 6:17 PM, Alex Williamson
> <alex.williamson@redhat.com> wrote:
>> On Thu, 2015-06-18 at 17:23 +0200, Baptiste Reynal wrote:
>>> Hello everyone,
>>>
>>> I tested and reviewed the patches, everything's fine for me.
>>
>> Hi Baptiste,
>>
>> Would you like to provide a Sign-off/Ack/Review tag for the series then?
>>
>>> I agree to be maintainer of vfio platform drivers, though I don't
>>> think the volume of patches about VFIO will justify a new mailing
>>> list.
>>
>> Ok, I'll officially post the patch for MAINTAINERS then. Until someone
>> complains, we'll continue to use the kvm list. Thanks,
>>
>> Alex
>>
>>> On Thu, Jun 18, 2015 at 12:31 AM, Alex Williamson
>>> <alex.williamson@redhat.com> wrote:
>>>> On Mon, 2015-06-15 at 11:09 +0200, Eric Auger wrote:
>>>>> In situations where the userspace driver is stopped abnormally and the
>>>>> VFIO platform device is released, the assigned HW device currently is
>>>>> left running. As a consequence the HW device might continue issuing IRQs
>>>>> and performing DMA accesses.
>>>>>
>>>>> On release, no physical IRQ handler is setup anymore. Also the DMA buffers
>>>>> are unmapped leading to IOMMU aborts. So there is no serious consequence.
>>>>>
>>>>> However when assigning that HW device again to another userspace driver,
>>>>> this latter might face some unexpected IRQs and DMA accesses, which are
>>>>> the result of the previous assignment.
>>>>>
>>>>> In virtualization use-case, a VM newly granted with that HW device may be
>>>>> impacted by the assignment of that device to a previous VM:
>>>>> - IRQs may be injected very early when booting the new guest, even before
>>>>> the guest driver has initialized leading to possible driver state
>>>>> inconsistency.
>>>>> - DMA accesses may hit the newly mapped VM address space at addresses that
>>>>> may jeopardize the integrity of the newly installed VM.
>>>>>
>>>>> Obviously the criticity depends on the assigned HW device.
>>>>>
>>>>> As opposed to PCI, there is no standard mechanism to reset the platform
>>>>> device.
>>>>>
>>>>> This series proposes to implement device specific reset functions in
>>>>> separate in-kernel vfio reset modules. The vfio-platform driver holds
>>>>> a whitelist of implemented triplets (compat string, module name,
>>>>> reset function name). When the vfio-platform driver is probed it identifies
>>>>> the fellow reset module/function matching the compat string of the
>>>>> device, if any, and forces the load of this reset module.
>>>>>
>>>>> A first reset module is provided: the vfio-platform-calxedaxgmac
>>>>> module which implements a basic reset for the Calxeda xgmac.
>>>>>
>>>>> The series can be found at
>>>>> https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.1-rc8-reset-v4
>>>>>
>>>>> History:
>>>>> v3 -> v4:
>>>>> - fix the commit message of "VFIO: platform: add reset struct and lookup table"
>>>>
>>>> Baptiste,
>>>>
>>>> Any comments? Should we also add something like this to MAINTAINERS
>>>> before we go much further?
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index d8afd29..c6bf7f6 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -10545,6 +10545,12 @@ F: drivers/vfio/
>>>> F: include/linux/vfio.h
>>>> F: include/uapi/linux/vfio.h
>>>>
>>>> +VFIO PLATFORM DRIVER
>>>> +M: Baptiste Reynal <b.reynal@virtualopensystems.com>
>>>> +L: kvm at vger.kernel.org
>>>> +S: Maintained
>>>> +F: drivers/vfio/platform/
>>>> +
>>>> VIDEOBUF2 FRAMEWORK
>>>> M: Pawel Osciak <pawel@osciak.com>
>>>> M: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>
>>>> I'm not sure what you want to be the primary list, maybe it's time to
>>>> ask for a vfio list. Thanks,
>>>> Alex
>>>>
>>>>>
>>>>> v2 -> v3:
>>>>> - remove void module_init/exit functions in calxeda reset module
>>>>> - remove enum vfio_platform_reset_type
>>>>> - for reset lookup, use ARRAY_SIZE
>>>>> - in reset put use symbol_put_addr
>>>>>
>>>>> v1 -> v2:
>>>>> - much simplified compared to v1 although principle of external modules is
>>>>> kept: removed mechanism of dynamic registration of reset functions
>>>>> - list is replaced by whitelist lookup table
>>>>> - name of the reset function also stored in the lookup table
>>>>> - autoload of reset modules
>>>>>
>>>>> RFC -> PATCH v1:
>>>>> - solution now based on a lookup list instead of specialized driver
>>>>>
>>>>>
>>>>> Eric Auger (4):
>>>>> VFIO: platform: add reset struct and lookup table
>>>>> VFIO: platform: add reset callback
>>>>> VFIO: platform: populate the reset function on probe
>>>>> VFIO: platform: Calxeda xgmac reset module
>>>>>
>>>>> drivers/vfio/platform/Kconfig | 2 +
>>>>> drivers/vfio/platform/Makefile | 2 +
>>>>> drivers/vfio/platform/reset/Kconfig | 7 ++
>>>>> drivers/vfio/platform/reset/Makefile | 5 ++
>>>>> .../platform/reset/vfio_platform_calxedaxgmac.c | 86 ++++++++++++++++++++++
>>>>> drivers/vfio/platform/vfio_platform_common.c | 60 ++++++++++++++-
>>>>> drivers/vfio/platform/vfio_platform_private.h | 7 ++
>>>>> 7 files changed, 166 insertions(+), 3 deletions(-)
>>>>> create mode 100644 drivers/vfio/platform/reset/Kconfig
>>>>> create mode 100644 drivers/vfio/platform/reset/Makefile
>>>>> create mode 100644 drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v4 0/4] VFIO platform reset
2015-06-19 7:53 ` Baptiste Reynal
2015-06-22 7:58 ` Eric Auger
@ 2015-06-22 15:43 ` Alex Williamson
1 sibling, 0 replies; 13+ messages in thread
From: Alex Williamson @ 2015-06-22 15:43 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2015-06-19 at 09:53 +0200, Baptiste Reynal wrote:
> [1-4/4]
> Acked-by: Baptiste Reynal <b.reynal@virtualopensystems.com>
> Tested-by: Baptiste Reynal <b.reynal@virtualopensystems.com>
> Reviewed-by: Baptiste Reynal <b.reynal@virtualopensystems.com>
FWIW, I think that Acked-by implies Reviewed-by, so I'll drop that tag,
but add the other two to the series. Eric also has this patch that
needs your ack:
https://lkml.org/lkml/2015/6/15/129
And I'd like one for this:
https://lkml.org/lkml/2015/6/18/631
I don't want it to appear that I'm volunteering you for this job ;)
Since the merge window just opened, I'd like to wrap-up the existing
on-list patches and get a pull request out. Thanks,
Alex
> On Thu, Jun 18, 2015 at 6:17 PM, Alex Williamson
> <alex.williamson@redhat.com> wrote:
> > On Thu, 2015-06-18 at 17:23 +0200, Baptiste Reynal wrote:
> >> Hello everyone,
> >>
> >> I tested and reviewed the patches, everything's fine for me.
> >
> > Hi Baptiste,
> >
> > Would you like to provide a Sign-off/Ack/Review tag for the series then?
> >
> >> I agree to be maintainer of vfio platform drivers, though I don't
> >> think the volume of patches about VFIO will justify a new mailing
> >> list.
> >
> > Ok, I'll officially post the patch for MAINTAINERS then. Until someone
> > complains, we'll continue to use the kvm list. Thanks,
> >
> > Alex
> >
> >> On Thu, Jun 18, 2015 at 12:31 AM, Alex Williamson
> >> <alex.williamson@redhat.com> wrote:
> >> > On Mon, 2015-06-15 at 11:09 +0200, Eric Auger wrote:
> >> >> In situations where the userspace driver is stopped abnormally and the
> >> >> VFIO platform device is released, the assigned HW device currently is
> >> >> left running. As a consequence the HW device might continue issuing IRQs
> >> >> and performing DMA accesses.
> >> >>
> >> >> On release, no physical IRQ handler is setup anymore. Also the DMA buffers
> >> >> are unmapped leading to IOMMU aborts. So there is no serious consequence.
> >> >>
> >> >> However when assigning that HW device again to another userspace driver,
> >> >> this latter might face some unexpected IRQs and DMA accesses, which are
> >> >> the result of the previous assignment.
> >> >>
> >> >> In virtualization use-case, a VM newly granted with that HW device may be
> >> >> impacted by the assignment of that device to a previous VM:
> >> >> - IRQs may be injected very early when booting the new guest, even before
> >> >> the guest driver has initialized leading to possible driver state
> >> >> inconsistency.
> >> >> - DMA accesses may hit the newly mapped VM address space at addresses that
> >> >> may jeopardize the integrity of the newly installed VM.
> >> >>
> >> >> Obviously the criticity depends on the assigned HW device.
> >> >>
> >> >> As opposed to PCI, there is no standard mechanism to reset the platform
> >> >> device.
> >> >>
> >> >> This series proposes to implement device specific reset functions in
> >> >> separate in-kernel vfio reset modules. The vfio-platform driver holds
> >> >> a whitelist of implemented triplets (compat string, module name,
> >> >> reset function name). When the vfio-platform driver is probed it identifies
> >> >> the fellow reset module/function matching the compat string of the
> >> >> device, if any, and forces the load of this reset module.
> >> >>
> >> >> A first reset module is provided: the vfio-platform-calxedaxgmac
> >> >> module which implements a basic reset for the Calxeda xgmac.
> >> >>
> >> >> The series can be found at
> >> >> https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.1-rc8-reset-v4
> >> >>
> >> >> History:
> >> >> v3 -> v4:
> >> >> - fix the commit message of "VFIO: platform: add reset struct and lookup table"
> >> >
> >> > Baptiste,
> >> >
> >> > Any comments? Should we also add something like this to MAINTAINERS
> >> > before we go much further?
> >> >
> >> > diff --git a/MAINTAINERS b/MAINTAINERS
> >> > index d8afd29..c6bf7f6 100644
> >> > --- a/MAINTAINERS
> >> > +++ b/MAINTAINERS
> >> > @@ -10545,6 +10545,12 @@ F: drivers/vfio/
> >> > F: include/linux/vfio.h
> >> > F: include/uapi/linux/vfio.h
> >> >
> >> > +VFIO PLATFORM DRIVER
> >> > +M: Baptiste Reynal <b.reynal@virtualopensystems.com>
> >> > +L: kvm at vger.kernel.org
> >> > +S: Maintained
> >> > +F: drivers/vfio/platform/
> >> > +
> >> > VIDEOBUF2 FRAMEWORK
> >> > M: Pawel Osciak <pawel@osciak.com>
> >> > M: Marek Szyprowski <m.szyprowski@samsung.com>
> >> >
> >> > I'm not sure what you want to be the primary list, maybe it's time to
> >> > ask for a vfio list. Thanks,
> >> > Alex
> >> >
> >> >>
> >> >> v2 -> v3:
> >> >> - remove void module_init/exit functions in calxeda reset module
> >> >> - remove enum vfio_platform_reset_type
> >> >> - for reset lookup, use ARRAY_SIZE
> >> >> - in reset put use symbol_put_addr
> >> >>
> >> >> v1 -> v2:
> >> >> - much simplified compared to v1 although principle of external modules is
> >> >> kept: removed mechanism of dynamic registration of reset functions
> >> >> - list is replaced by whitelist lookup table
> >> >> - name of the reset function also stored in the lookup table
> >> >> - autoload of reset modules
> >> >>
> >> >> RFC -> PATCH v1:
> >> >> - solution now based on a lookup list instead of specialized driver
> >> >>
> >> >>
> >> >> Eric Auger (4):
> >> >> VFIO: platform: add reset struct and lookup table
> >> >> VFIO: platform: add reset callback
> >> >> VFIO: platform: populate the reset function on probe
> >> >> VFIO: platform: Calxeda xgmac reset module
> >> >>
> >> >> drivers/vfio/platform/Kconfig | 2 +
> >> >> drivers/vfio/platform/Makefile | 2 +
> >> >> drivers/vfio/platform/reset/Kconfig | 7 ++
> >> >> drivers/vfio/platform/reset/Makefile | 5 ++
> >> >> .../platform/reset/vfio_platform_calxedaxgmac.c | 86 ++++++++++++++++++++++
> >> >> drivers/vfio/platform/vfio_platform_common.c | 60 ++++++++++++++-
> >> >> drivers/vfio/platform/vfio_platform_private.h | 7 ++
> >> >> 7 files changed, 166 insertions(+), 3 deletions(-)
> >> >> create mode 100644 drivers/vfio/platform/reset/Kconfig
> >> >> create mode 100644 drivers/vfio/platform/reset/Makefile
> >> >> create mode 100644 drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
> >> >>
> >> >
> >> >
> >> >
> >
> >
> >
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v4 0/4] VFIO platform reset
2015-06-15 9:09 [PATCH v4 0/4] VFIO platform reset Eric Auger
` (4 preceding siblings ...)
2015-06-17 22:31 ` [PATCH v4 0/4] VFIO platform reset Alex Williamson
@ 2015-08-27 11:56 ` Eric Auger
2015-08-27 13:05 ` Eric Auger
5 siblings, 1 reply; 13+ messages in thread
From: Eric Auger @ 2015-08-27 11:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi Marc,
I tested the series on Calxeda Midway with VFIO use case. Also reviewed
it again without finding anything new.
Tested-by: Eric Auger <eric.auger@linaro.org>
Reviewed-by: Eric Auger <eric.auger@linaro.org>
Best Regards
Eric
On 06/15/2015 11:09 AM, Eric Auger wrote:
> In situations where the userspace driver is stopped abnormally and the
> VFIO platform device is released, the assigned HW device currently is
> left running. As a consequence the HW device might continue issuing IRQs
> and performing DMA accesses.
>
> On release, no physical IRQ handler is setup anymore. Also the DMA buffers
> are unmapped leading to IOMMU aborts. So there is no serious consequence.
>
> However when assigning that HW device again to another userspace driver,
> this latter might face some unexpected IRQs and DMA accesses, which are
> the result of the previous assignment.
>
> In virtualization use-case, a VM newly granted with that HW device may be
> impacted by the assignment of that device to a previous VM:
> - IRQs may be injected very early when booting the new guest, even before
> the guest driver has initialized leading to possible driver state
> inconsistency.
> - DMA accesses may hit the newly mapped VM address space at addresses that
> may jeopardize the integrity of the newly installed VM.
>
> Obviously the criticity depends on the assigned HW device.
>
> As opposed to PCI, there is no standard mechanism to reset the platform
> device.
>
> This series proposes to implement device specific reset functions in
> separate in-kernel vfio reset modules. The vfio-platform driver holds
> a whitelist of implemented triplets (compat string, module name,
> reset function name). When the vfio-platform driver is probed it identifies
> the fellow reset module/function matching the compat string of the
> device, if any, and forces the load of this reset module.
>
> A first reset module is provided: the vfio-platform-calxedaxgmac
> module which implements a basic reset for the Calxeda xgmac.
>
> The series can be found at
> https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.1-rc8-reset-v4
>
> History:
> v3 -> v4:
> - fix the commit message of "VFIO: platform: add reset struct and lookup table"
>
> v2 -> v3:
> - remove void module_init/exit functions in calxeda reset module
> - remove enum vfio_platform_reset_type
> - for reset lookup, use ARRAY_SIZE
> - in reset put use symbol_put_addr
>
> v1 -> v2:
> - much simplified compared to v1 although principle of external modules is
> kept: removed mechanism of dynamic registration of reset functions
> - list is replaced by whitelist lookup table
> - name of the reset function also stored in the lookup table
> - autoload of reset modules
>
> RFC -> PATCH v1:
> - solution now based on a lookup list instead of specialized driver
>
>
> Eric Auger (4):
> VFIO: platform: add reset struct and lookup table
> VFIO: platform: add reset callback
> VFIO: platform: populate the reset function on probe
> VFIO: platform: Calxeda xgmac reset module
>
> drivers/vfio/platform/Kconfig | 2 +
> drivers/vfio/platform/Makefile | 2 +
> drivers/vfio/platform/reset/Kconfig | 7 ++
> drivers/vfio/platform/reset/Makefile | 5 ++
> .../platform/reset/vfio_platform_calxedaxgmac.c | 86 ++++++++++++++++++++++
> drivers/vfio/platform/vfio_platform_common.c | 60 ++++++++++++++-
> drivers/vfio/platform/vfio_platform_private.h | 7 ++
> 7 files changed, 166 insertions(+), 3 deletions(-)
> create mode 100644 drivers/vfio/platform/reset/Kconfig
> create mode 100644 drivers/vfio/platform/reset/Makefile
> create mode 100644 drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
>
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH v4 0/4] VFIO platform reset
2015-08-27 11:56 ` Eric Auger
@ 2015-08-27 13:05 ` Eric Auger
0 siblings, 0 replies; 13+ messages in thread
From: Eric Auger @ 2015-08-27 13:05 UTC (permalink / raw)
To: linux-arm-kernel
Dear all,
Please ignore this email. It is a reply to a wrong thread (was targeting
[PATCH v4 0/4] irqchip: GICv2/v3: Add support for irq_vcpu_affinity).
My apologies
Best Regards
Eric
On 08/27/2015 01:56 PM, Eric Auger wrote:
> Hi Marc,
>
> I tested the series on Calxeda Midway with VFIO use case. Also reviewed
> it again without finding anything new.
>
> Tested-by: Eric Auger <eric.auger@linaro.org>
> Reviewed-by: Eric Auger <eric.auger@linaro.org>
>
> Best Regards
>
> Eric
>
> On 06/15/2015 11:09 AM, Eric Auger wrote:
>> In situations where the userspace driver is stopped abnormally and the
>> VFIO platform device is released, the assigned HW device currently is
>> left running. As a consequence the HW device might continue issuing IRQs
>> and performing DMA accesses.
>>
>> On release, no physical IRQ handler is setup anymore. Also the DMA buffers
>> are unmapped leading to IOMMU aborts. So there is no serious consequence.
>>
>> However when assigning that HW device again to another userspace driver,
>> this latter might face some unexpected IRQs and DMA accesses, which are
>> the result of the previous assignment.
>>
>> In virtualization use-case, a VM newly granted with that HW device may be
>> impacted by the assignment of that device to a previous VM:
>> - IRQs may be injected very early when booting the new guest, even before
>> the guest driver has initialized leading to possible driver state
>> inconsistency.
>> - DMA accesses may hit the newly mapped VM address space at addresses that
>> may jeopardize the integrity of the newly installed VM.
>>
>> Obviously the criticity depends on the assigned HW device.
>>
>> As opposed to PCI, there is no standard mechanism to reset the platform
>> device.
>>
>> This series proposes to implement device specific reset functions in
>> separate in-kernel vfio reset modules. The vfio-platform driver holds
>> a whitelist of implemented triplets (compat string, module name,
>> reset function name). When the vfio-platform driver is probed it identifies
>> the fellow reset module/function matching the compat string of the
>> device, if any, and forces the load of this reset module.
>>
>> A first reset module is provided: the vfio-platform-calxedaxgmac
>> module which implements a basic reset for the Calxeda xgmac.
>>
>> The series can be found at
>> https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.1-rc8-reset-v4
>>
>> History:
>> v3 -> v4:
>> - fix the commit message of "VFIO: platform: add reset struct and lookup table"
>>
>> v2 -> v3:
>> - remove void module_init/exit functions in calxeda reset module
>> - remove enum vfio_platform_reset_type
>> - for reset lookup, use ARRAY_SIZE
>> - in reset put use symbol_put_addr
>>
>> v1 -> v2:
>> - much simplified compared to v1 although principle of external modules is
>> kept: removed mechanism of dynamic registration of reset functions
>> - list is replaced by whitelist lookup table
>> - name of the reset function also stored in the lookup table
>> - autoload of reset modules
>>
>> RFC -> PATCH v1:
>> - solution now based on a lookup list instead of specialized driver
>>
>>
>> Eric Auger (4):
>> VFIO: platform: add reset struct and lookup table
>> VFIO: platform: add reset callback
>> VFIO: platform: populate the reset function on probe
>> VFIO: platform: Calxeda xgmac reset module
>>
>> drivers/vfio/platform/Kconfig | 2 +
>> drivers/vfio/platform/Makefile | 2 +
>> drivers/vfio/platform/reset/Kconfig | 7 ++
>> drivers/vfio/platform/reset/Makefile | 5 ++
>> .../platform/reset/vfio_platform_calxedaxgmac.c | 86 ++++++++++++++++++++++
>> drivers/vfio/platform/vfio_platform_common.c | 60 ++++++++++++++-
>> drivers/vfio/platform/vfio_platform_private.h | 7 ++
>> 7 files changed, 166 insertions(+), 3 deletions(-)
>> create mode 100644 drivers/vfio/platform/reset/Kconfig
>> create mode 100644 drivers/vfio/platform/reset/Makefile
>> create mode 100644 drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
>>
>
^ permalink raw reply [flat|nested] 13+ messages in thread