[PATCH v4 0/4] VFIO platform reset

[PATCH v4 0/4] VFIO platform reset

[Eric Auger]

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

-- 
1.9.1

[PATCH v4 0/4] VFIO platform reset

[Eric Auger]

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

-- 
1.9.1

[PATCH v4 1/4] VFIO: platform: add reset struct and lookup table

[Eric Auger]

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

[PATCH v4 1/4] VFIO: platform: add reset struct and lookup table

[Eric Auger]

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

[PATCH v4 2/4] VFIO: platform: add reset callback

[Eric Auger]

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

[PATCH v4 2/4] VFIO: platform: add reset callback

[Eric Auger]

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

[PATCH v4 3/4] VFIO: platform: populate the reset function on probe

[Eric Auger]

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

[PATCH v4 3/4] VFIO: platform: populate the reset function on probe

[Eric Auger]

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

[PATCH v4 4/4] VFIO: platform: Calxeda xgmac reset module

[Eric Auger]

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

[PATCH v4 4/4] VFIO: platform: Calxeda xgmac reset module

[Eric Auger]

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

Re: [PATCH v4 0/4] VFIO platform reset

[Alex Williamson]

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@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
> 

[PATCH v4 0/4] VFIO platform reset

[Alex Williamson]

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
> 

Re: [PATCH v4 0/4] VFIO platform reset

[Baptiste Reynal]

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@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
>>
>
>
>

[PATCH v4 0/4] VFIO platform reset

[Baptiste Reynal]

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
>>
>
>
>

Re: [PATCH v4 0/4] VFIO platform reset

[Alex Williamson]

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@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
> >>
> >
> >
> >

[PATCH v4 0/4] VFIO platform reset

[Alex Williamson]

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
> >>
> >
> >
> >

Re: [PATCH v4 0/4] VFIO platform reset

[Baptiste Reynal]

[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@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
>> >>
>> >
>> >
>> >
>
>
>

[PATCH v4 0/4] VFIO platform reset

[Baptiste Reynal]

[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
>> >>
>> >
>> >
>> >
>
>
>

[PATCH v4 0/4] VFIO platform reset

[Eric Auger]

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
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>

Re: [PATCH v4 0/4] VFIO platform reset

[Alex Williamson]

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@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
> >> >>
> >> >
> >> >
> >> >
> >
> >
> >



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 0/4] VFIO platform reset

[Alex Williamson]

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
> >> >>
> >> >
> >> >
> >> >
> >
> >
> >

Re: [PATCH v4 0/4] VFIO platform reset

[Eric Auger]

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
> 

[PATCH v4 0/4] VFIO platform reset

[Eric Auger]

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
> 

Re: [PATCH v4 0/4] VFIO platform reset

[Eric Auger]

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
>>
> 

[PATCH v4 0/4] VFIO platform reset

[Eric Auger]

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
>>
>