vfio: platform: return device properties for a platform device

This patch introduced the API to return device properties about

a PLATFORM device (if described by a device tree or ACPI) and the skeleton of the implementation for VFIO_PLATFORM. Information about any device node bound by VFIO_PLATFORM should be queried via the introduced ioctl VFIO_DEVICE_GET_DEV_PROPERTY.

The user needs to know the name and the data type of the property he is accessing.

Signed-off-by Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/[email protected]>

---
 drivers/vfio/platform/Makefile                |  3 +-
 drivers/vfio/platform/properties.c            | 61 +++++++++++++++++++++++++++
 drivers/vfio/platform/vfio_platform_common.c  | 35 +++++++++++++++
 drivers/vfio/platform/vfio_platform_private.h |  7 +++
 include/uapi/linux/vfio.h                     | 26 ++++++++++++
 5 files changed, 131 insertions(+), 1 deletion(-)
 create mode 100644 drivers/vfio/platform/properties.c

drivers/vfio/platform/Makefile +0 -0

index 81de144..99f3ba1 100644

drivers/vfio/platform/properties.c new file +61 -0

@@ -0,0 +1,61 @@
+#include <linux/slab.h>
+#include <linux/vfio.h>
+#include <linux/property.h>
+#include "vfio_platform_private.h"
+
+static int dev_property_get_strings(struct device *dev,
+				    char *name, unsigned *lenp,
+				    void __user *datap, unsigned long datasz)
+{
+	return -EINVAL;
+}
+
+static int dev_property_get_uint(struct device *dev, char *name,
+				 uint32_t type, unsigned *lenp,
+				 void __user *datap, unsigned long datasz)
+{
+	return -EINVAL;
+}
+
+int vfio_platform_dev_properties(struct device *dev,
+				 uint32_t type, unsigned *lenp,
+				 void __user *datap, unsigned long datasz)
+{
+	char *name;
+	long namesz;
+	int ret;
+
+	namesz = strnlen_user(datap, datasz);
+	if (!namesz)
+		return -EFAULT;
+	if (namesz > datasz)
+		return -EINVAL;
+
+	name = kzalloc(namesz, GFP_KERNEL);
+	if (!name)
+		return -ENOMEM;
+	if (strncpy_from_user(name, datap, namesz) <= 0) {
+		kfree(name);
+		return -EFAULT;
+	}
+
+	switch (type) {
+	case VFIO_DEV_PROPERTY_TYPE_STRINGS:
+		ret = dev_property_get_strings(dev, name, lenp, datap, datasz);
+		break;
+
+	case VFIO_DEV_PROPERTY_TYPE_U64:
+	case VFIO_DEV_PROPERTY_TYPE_U32:
+	case VFIO_DEV_PROPERTY_TYPE_U16:
+	case VFIO_DEV_PROPERTY_TYPE_U8:
+		ret = dev_property_get_uint(dev, name, type, lenp,
+					    datap, datasz);
+		break;
+
+	default:
+		ret = -EINVAL;
+	}
+
+	kfree(name);
+	return ret;
+}

drivers/vfio/platform/vfio_platform_common.c +35 -0

index a532a25..83ad4b74 100644
@@ -19,6 +19,7 @@
 #include <linux/slab.h>
 #include <linux/types.h>
 #include <linux/vfio.h>
+#include <linux/property.h>
 
 #include "vfio_platform_private.h"
 

@@ -251,6 +252,34 @@ static long vfio_platform_ioctl(void *device_data,
 
 		return ret;
 
+	} else if (cmd == VFIO_DEVICE_GET_DEV_PROPERTY) {
+		struct vfio_dev_property info;
+		void __user *datap;
+		unsigned long datasz;
+		int ret;
+
+		if (!vdev->dev)
+			return -EINVAL;
+
+		minsz = offsetofend(struct vfio_dev_property, length);
+
+		if (copy_from_user(&info, (void __user *)arg, minsz))
+			return -EFAULT;
+
+		if (info.argsz < minsz)
+			return -EINVAL;
+
+		datap = (void __user *) arg + minsz;
+		datasz = info.argsz - minsz;
+
+		ret = vfio_platform_dev_properties(vdev->dev, info.type,
+						   &info.length, datap, datasz);
+
+		if (copy_to_user((void __user *)arg, &info, minsz))
+			ret = -EFAULT;
+
+		return ret;
+
 	} else if (cmd == VFIO_DEVICE_RESET)
 		return -EINVAL;
 

@@ -501,6 +530,12 @@ int vfio_platform_probe_common(struct vfio_platform_device *vdev,
 		return ret;
 	}
 
+	/* add device properties flag */
+	if (device_property_present(dev, "name")) {
+		vdev->dev = dev;
+		vdev->flags |= VFIO_DEVICE_FLAGS_DEV_PROPERTIES;
+	}
+
 	mutex_init(&vdev->igate);
 
 	return 0;

drivers/vfio/platform/vfio_platform_private.h +1 -0

index c3d5b4b..fc6b1fb 100644
@@ -53,6 +53,7 @@ struct vfio_platform_device {
 	u32				num_irqs;
 	int				refcnt;
 	struct mutex			igate;
+	struct device			*dev;
 
 	/*
 	 * These fields should be filled by the bus specific binder

drivers/vfio/platform/vfio_platform_private.h +5 -0

+extern int vfio_platform_dev_properties(struct device *dev,
+					uint32_t type, unsigned *lenp,
+					void __user *datap,
+					unsigned long datasz);
+
 #endif /* VFIO_PLATFORM_PRIVATE_H */

include/uapi/linux/vfio.h +1 -0

index 544d3d8..ac50ab3f 100644
@@ -161,12 +161,38 @@ struct vfio_device_info {
 #define VFIO_DEVICE_FLAGS_PCI	(1 << 1)	/* vfio-pci device */
 #define VFIO_DEVICE_FLAGS_PLATFORM (1 << 2)	/* vfio-platform device */
 #define VFIO_DEVICE_FLAGS_AMBA  (1 << 3)	/* vfio-amba device */
+#define VFIO_DEVICE_FLAGS_DEV_PROPERTIES (1 << 4) /* Device properties */

include/uapi/linux/vfio.h +2 -0

+
+/**
  * VFIO_DEVICE_GET_REGION_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 8,
  *				       struct vfio_region_info)
  *

Certain device properties (e.g. the device node name, the compatible string), are available as a list of strings (separated by the null terminating character). Let the VFIO user query this type of properties.

Signed-off-by Antonios Motakis <[email protected]>

---
 drivers/vfio/platform/properties.c | 43 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 42 insertions(+), 1 deletion(-)

drivers/vfio/platform/properties.c +0 -0

index 8b90465..39c6342 100644
@@ -7,7 +7,48 @@ static int dev_property_get_strings(struct device *dev,
 				    char *name, unsigned *lenp,

drivers/vfio/platform/properties.c +9 -0

+
+		*lenp += len;
+		datap += len;
+		datasz -= len;
+	}
+
+out:
+	kfree(val);
+	return ret;
 }
 
 static int dev_property_get_uint(struct device *dev, char *name,

Certain properties of a device are accessible as an array of unsigned integers, either u64, u32, u16, or u8. Let the VFIO user query this type of device properties.

Signed-off-by Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/[email protected]>

---
 drivers/vfio/platform/properties.c | 62 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 61 insertions(+), 1 deletion(-)

drivers/vfio/platform/properties.c +33 -1

index 39c6342..645f6e5c 100644
@@ -55,7 +55,67 @@ static int dev_property_get_uint(struct device *dev, char *name,
 				 uint32_t type, unsigned *lenp,
 				 void __user *datap, unsigned long datasz)
 {
-	return -EINVAL;
+	int ret, n;
+	u8 *out;
+	size_t sz;
+	int (*func)(const struct device *, const char *, void *, size_t)
+		= NULL;
+
+	switch (type) {
+	case VFIO_DEV_PROPERTY_TYPE_U64:
+		sz = sizeof(u64);
+		func = (int (*)(const struct device *,
+				const char *, void *, size_t))
+			device_property_read_u64_array;
+		break;
+	case VFIO_DEV_PROPERTY_TYPE_U32:
+		sz = sizeof(u32);
+		func = (int (*)(const struct device *,
+				const char *, void *, size_t))
+			device_property_read_u32_array;
+		break;
+	case VFIO_DEV_PROPERTY_TYPE_U16:
+		sz = sizeof(u16);
+		func = (int (*)(const struct device *,
+				const char *, void *, size_t))
+			device_property_read_u16_array;
+		break;
+	case VFIO_DEV_PROPERTY_TYPE_U8:
+		sz = sizeof(u8);
+		func = (int (*)(const struct device *,
+				const char *, void *, size_t))
+			device_property_read_u8_array;
+		break;
+
+	default:

drivers/vfio/platform/properties.c +11 -0

+
+	ret = func(dev, name, out, n);
+	if (ret)
+		goto out;
+
+	if (copy_to_user(datap, out, n * sz))
+		ret = -EFAULT;
+
+out:
+	kfree(out);
+	return ret;
 }
 
 int vfio_platform_dev_properties(struct device *dev,

This RFC's intention is to show what an interface to access device properties for the VFIO platform driver can look like. These properties can be from the device tree node describing the device, or ACPI properties in the future.

If a device property corresponding to a platform device bound by VFIO PLATFORM or VFIO AMBA is available, this patch series will allow the user to query for this information. This can be useful for userspace drivers to automatically query parameters related to the device.

Specifically for QEMU, reading the "compatible" property of the device tree node could be of use to find out what device is being assigned to the guest and handle appropriately a wider range of devices in the future, and to generate an appropriate device tree for the guest.

Older versions of this series where specifically targeted at device tree properties. This version has been reworked on top of Rafael J. Wysocki's uniform device properties API for device tree and ACPI devices. This will allow us to use the API in the future with devices described via ACPI.

This also means a kernel including the uniform device properties API is needed to apply these patches, in additon to the VFIO patches, e.g. branch pm+acpi-3.19-rc1 from https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/

The API to get the list of available properties and the device tree full_name have been removed. These probably don't serve an useful purpose, as the user of this API need to know anyway what properties are specific to the device he wants to access with VFIO. If we decide to reintroduce the list of properties in the future, the generic device properties API in the kernel will have to be extended accordingly.

A kernel with this series and all the dependencies applied can be pulled from branch vfio-device-properties-v3 from the repository:
https://github.com/virtualopensystems/linux-kvm-arm.git

Changes since v2:
- Reworked on top of Rafael J. Wysocki's uniform device properties API for device tree and ACPI
- Support for u64 array properties
- Removed API to get list of available properties and device tree full_name
Changes since v1:
- Updated for VFIO platform patch series v8:
VFIO AMBA devices now supported in addition to VFIO PLATFORM devices
- Refactored and cleaned up the code

Antonios Motakis (3):
vfio: platform: add device properties skeleton and user API
vfio: platform: access device property as a list of strings
vfio: platform: return device properties as arrays of unsigned
integers

 drivers/vfio/platform/Makefile                |   3 +-
 drivers/vfio/platform/properties.c            | 162 ++++++++++++++++++++++++++
 drivers/vfio/platform/vfio_platform_common.c  |  35 ++++++
 drivers/vfio/platform/vfio_platform_private.h |   7 ++
 include/uapi/linux/vfio.h                     |  26 +++++
 5 files changed, 232 insertions(+), 1 deletion(-)
 create mode 100644 drivers/vfio/platform/properties.c

Hi Baptiste, Antonios,

What are the plans wrt this series? I am currently integrating another QEMU VFIO platform devices where this series could be useful I think (Feb 2015). Do you intend to follow up and bring it upstream?

Alex, do you see some show-stoppers in this series or do you advise to simply follow-up?

Thank you in advance

Best Regards

Eric

Quoted 59 lines · Antonios Motakis

This RFC's intention is to show what an interface to access device properties for the VFIO platform driver can look like. These properties can be from the device tree node describing the device, or ACPI properties in the future.

If a device property corresponding to a platform device bound by VFIO PLATFORM or VFIO AMBA is available, this patch series will allow the user to query for this information. This can be useful for userspace drivers to automatically query parameters related to the device.

Specifically for QEMU, reading the "compatible" property of the device tree node could be of use to find out what device is being assigned to the guest and handle appropriately a wider range of devices in the future, and to generate an appropriate device tree for the guest.

Older versions of this series where specifically targeted at device tree properties. This version has been reworked on top of Rafael J. Wysocki's uniform device properties API for device tree and ACPI devices. This will allow us to use the API in the future with devices described via ACPI.

This also means a kernel including the uniform device properties API is needed to apply these patches, in additon to the VFIO patches, e.g. branch pm+acpi-3.19-rc1 from https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/

The API to get the list of available properties and the device tree full_name have been removed. These probably don't serve an useful purpose, as the user of this API need to know anyway what properties are specific to the device he wants to access with VFIO. If we decide to reintroduce the list of properties in the future, the generic device properties API in the kernel will have to be extended accordingly.

A kernel with this series and all the dependencies applied can be pulled from branch vfio-device-properties-v3 from the repository:
https://github.com/virtualopensystems/linux-kvm-arm.git

Changes since v2:
- Reworked on top of Rafael J. Wysocki's uniform device properties API for device tree and ACPI
- Support for u64 array properties
- Removed API to get list of available properties and device tree full_name
Changes since v1:
- Updated for VFIO platform patch series v8:
VFIO AMBA devices now supported in addition to VFIO PLATFORM devices
- Refactored and cleaned up the code

Antonios Motakis (3):
vfio: platform: add device properties skeleton and user API
vfio: platform: access device property as a list of strings
vfio: platform: return device properties as arrays of unsigned
integers

 drivers/vfio/platform/Makefile                |   3 +-
 drivers/vfio/platform/properties.c            | 162 ++++++++++++++++++++++++++
 drivers/vfio/platform/vfio_platform_common.c  |  35 ++++++
 drivers/vfio/platform/vfio_platform_private.h |   7 ++
 include/uapi/linux/vfio.h                     |  26 +++++
 5 files changed, 232 insertions(+), 1 deletion(-)
 create mode 100644 drivers/vfio/platform/properties.c

Hello Eric,

Myself I am not involved with anything VFIO related at the moment, so (alas) I don't have any plans to revisit this series.

If someone decides to pick it up, of course I can offer my feedback and support.

Cheers,
Antonios

Quoted 77 lines · Eric Auger

Hi Baptiste, Antonios,

What are the plans wrt this series? I am currently integrating another QEMU VFIO platform devices where this series could be useful I think (Feb 2015). Do you intend to follow up and bring it upstream?

Alex, do you see some show-stoppers in this series or do you advise to simply follow-up?

Thank you in advance

Best Regards

Eric

Quoted 59 lines · Antonios Motakis

This RFC's intention is to show what an interface to access device properties for the VFIO platform driver can look like. These properties can be from the device tree node describing the device, or ACPI properties in the future.

If a device property corresponding to a platform device bound by VFIO PLATFORM or VFIO AMBA is available, this patch series will allow the user to query for this information. This can be useful for userspace drivers to automatically query parameters related to the device.

Specifically for QEMU, reading the "compatible" property of the device tree node could be of use to find out what device is being assigned to the guest and handle appropriately a wider range of devices in the future, and to generate an appropriate device tree for the guest.

Older versions of this series where specifically targeted at device tree properties. This version has been reworked on top of Rafael J. Wysocki's uniform device properties API for device tree and ACPI devices. This will allow us to use the API in the future with devices described via ACPI.

This also means a kernel including the uniform device properties API is needed to apply these patches, in additon to the VFIO patches, e.g. branch pm+acpi-3.19-rc1 from https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/

The API to get the list of available properties and the device tree full_name have been removed. These probably don't serve an useful purpose, as the user of this API need to know anyway what properties are specific to the device he wants to access with VFIO. If we decide to reintroduce the list of properties in the future, the generic device properties API in the kernel will have to be extended accordingly.

A kernel with this series and all the dependencies applied can be pulled from branch vfio-device-properties-v3 from the repository:
https://github.com/virtualopensystems/linux-kvm-arm.git

Changes since v2:
- Reworked on top of Rafael J. Wysocki's uniform device properties API for device tree and ACPI
- Support for u64 array properties
- Removed API to get list of available properties and device tree full_name
Changes since v1:
- Updated for VFIO platform patch series v8:
VFIO AMBA devices now supported in addition to VFIO PLATFORM devices
- Refactored and cleaned up the code

Antonios Motakis (3):
vfio: platform: add device properties skeleton and user API
vfio: platform: access device property as a list of strings
vfio: platform: return device properties as arrays of unsigned
integers

 drivers/vfio/platform/Makefile                |   3 +-
 drivers/vfio/platform/properties.c            | 162 ++++++++++++++++++++++++++
 drivers/vfio/platform/vfio_platform_common.c  |  35 ++++++
 drivers/vfio/platform/vfio_platform_private.h |   7 ++
 include/uapi/linux/vfio.h                     |  26 +++++
 5 files changed, 232 insertions(+), 1 deletion(-)
 create mode 100644 drivers/vfio/platform/properties.c

Hi Baptiste, Antonios,

What are the plans wrt this series? I am currently integrating another QEMU VFIO platform devices where this series could be useful I think (Feb 2015). Do you intend to follow up and bring it upstream?

Alex, do you see some show-stoppers in this series or do you advise to simply follow-up?

Thank you in advance

Best Regards

Eric

Quoted 59 lines · Antonios Motakis

This RFC's intention is to show what an interface to access device properties for the VFIO platform driver can look like. These properties can be from the device tree node describing the device, or ACPI properties in the future.

If a device property corresponding to a platform device bound by VFIO PLATFORM or VFIO AMBA is available, this patch series will allow the user to query for this information. This can be useful for userspace drivers to automatically query parameters related to the device.

Specifically for QEMU, reading the "compatible" property of the device tree node could be of use to find out what device is being assigned to the guest and handle appropriately a wider range of devices in the future, and to generate an appropriate device tree for the guest.

Older versions of this series where specifically targeted at device tree properties. This version has been reworked on top of Rafael J. Wysocki's uniform device properties API for device tree and ACPI devices. This will allow us to use the API in the future with devices described via ACPI.

This also means a kernel including the uniform device properties API is needed to apply these patches, in additon to the VFIO patches, e.g. branch pm+acpi-3.19-rc1 from https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/

The API to get the list of available properties and the device tree full_name have been removed. These probably don't serve an useful purpose, as the user of this API need to know anyway what properties are specific to the device he wants to access with VFIO. If we decide to reintroduce the list of properties in the future, the generic device properties API in the kernel will have to be extended accordingly.

A kernel with this series and all the dependencies applied can be pulled from branch vfio-device-properties-v3 from the repository:
https://github.com/virtualopensystems/linux-kvm-arm.git

Changes since v2:
- Reworked on top of Rafael J. Wysocki's uniform device properties API for device tree and ACPI
- Support for u64 array properties
- Removed API to get list of available properties and device tree full_name
Changes since v1:
- Updated for VFIO platform patch series v8:
VFIO AMBA devices now supported in addition to VFIO PLATFORM devices
- Refactored and cleaned up the code

Antonios Motakis (3):
vfio: platform: add device properties skeleton and user API
vfio: platform: access device property as a list of strings
vfio: platform: return device properties as arrays of unsigned
integers

  drivers/vfio/platform/Makefile                |   3 +-
  drivers/vfio/platform/properties.c            | 162 ++++++++++++++++++++++++++
  drivers/vfio/platform/vfio_platform_common.c  |  35 ++++++
  drivers/vfio/platform/vfio_platform_private.h |   7 ++
  include/uapi/linux/vfio.h                     |  26 +++++
  5 files changed, 232 insertions(+), 1 deletion(-)

create mode 100644 drivers/vfio/platform/properties.c

Hello Eric,

We intend to follow-up on this patch series to have it upstream depending on the comments of the community.

Best,

Christian

Quoted 95 lines · Eric Auger

Hi Baptiste, Antonios,

What are the plans wrt this series? I am currently integrating another QEMU VFIO platform devices where this series could be useful I think (Feb 2015). Do you intend to follow up and bring it upstream?

Alex, do you see some show-stoppers in this series or do you advise to simply follow-up?

Thank you in advance

Best Regards

Eric

Quoted 78 lines · Antonios Motakis

This RFC's intention is to show what an interface to access device properties for the VFIO platform driver can look like. These properties can be from the device tree node describing the device, or ACPI properties
in the future.

If a device property corresponding to a platform device bound by VFIO PLATFORM
or VFIO AMBA is available, this patch series will allow the user to query
for this information. This can be useful for userspace drivers to automatically
query parameters related to the device.

Specifically for QEMU, reading the "compatible" property of the device tree
node could be of use to find out what device is being assigned to the guest and
handle appropriately a wider range of devices in the future, and to generate an
appropriate device tree for the guest.

Older versions of this series where specifically targeted at device tree properties. This version has been reworked on top of Rafael J. Wysocki's uniform device properties API for device tree and ACPI devices. This will allow
us to use the API in the future with devices described via ACPI.

This also means a kernel including the uniform device properties API is needed
to apply these patches, in additon to the VFIO patches, e.g. branch pm+acpi-3.19-rc1
from https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/

The API to get the list of available properties and the device tree full_name
have been removed. These probably don't serve an useful purpose, as the user
of this API need to know anyway what properties are specific to the device he
wants to access with VFIO. If we decide to reintroduce the list of properties
in the future, the generic device properties API in the kernel will have to
be extended accordingly.

A kernel with this series and all the dependencies applied can be pulled from
branch vfio-device-properties-v3 from the repository:
https://github.com/virtualopensystems/linux-kvm-arm.git

Changes since v2:
- Reworked on top of Rafael J. Wysocki's uniform device properties
API for
device tree and ACPI
- Support for u64 array properties
- Removed API to get list of available properties and device tree
full_name
Changes since v1:
- Updated for VFIO platform patch series v8:
VFIO AMBA devices now supported in addition to VFIO PLATFORM devices
- Refactored and cleaned up the code

Antonios Motakis (3):
vfio: platform: add device properties skeleton and user API
vfio: platform: access device property as a list of strings
vfio: platform: return device properties as arrays of unsigned
integers

  drivers/vfio/platform/Makefile                |   3 +-
  drivers/vfio/platform/properties.c            | 162
++++++++++++++++++++++++++
  drivers/vfio/platform/vfio_platform_common.c  |  35 ++++++
  drivers/vfio/platform/vfio_platform_private.h |   7 ++
  include/uapi/linux/vfio.h                     |  26 +++++
  5 files changed, 232 insertions(+), 1 deletion(-)

create mode 100644 drivers/vfio/platform/properties.c

Hi Baptiste, Antonios,

What are the plans wrt this series? I am currently integrating another QEMU VFIO platform devices where this series could be useful I think (Feb 2015). Do you intend to follow up and bring it upstream?

Alex, do you see some show-stoppers in this series or do you advise to simply follow-up?

Quoted 59 lines

This RFC's intention is to show what an interface to access device properties for the VFIO platform driver can look like. These properties can be from the device tree node describing the device, or ACPI properties in the future.

If a device property corresponding to a platform device bound by VFIO PLATFORM or VFIO AMBA is available, this patch series will allow the user to query for this information. This can be useful for userspace drivers to automatically query parameters related to the device.

Specifically for QEMU, reading the "compatible" property of the device tree node could be of use to find out what device is being assigned to the guest and handle appropriately a wider range of devices in the future, and to generate an appropriate device tree for the guest.

Older versions of this series where specifically targeted at device tree properties. This version has been reworked on top of Rafael J. Wysocki's uniform device properties API for device tree and ACPI devices. This will allow us to use the API in the future with devices described via ACPI.

This also means a kernel including the uniform device properties API is needed to apply these patches, in additon to the VFIO patches, e.g. branch pm+acpi-3.19-rc1 from https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/

The API to get the list of available properties and the device tree full_name have been removed. These probably don't serve an useful purpose, as the user of this API need to know anyway what properties are specific to the device he wants to access with VFIO. If we decide to reintroduce the list of properties in the future, the generic device properties API in the kernel will have to be extended accordingly.

A kernel with this series and all the dependencies applied can be pulled from branch vfio-device-properties-v3 from the repository:
https://github.com/virtualopensystems/linux-kvm-arm.git

Changes since v2:
- Reworked on top of Rafael J. Wysocki's uniform device properties API for device tree and ACPI
- Support for u64 array properties
- Removed API to get list of available properties and device tree full_name
Changes since v1:
- Updated for VFIO platform patch series v8:
VFIO AMBA devices now supported in addition to VFIO PLATFORM devices
- Refactored and cleaned up the code

Antonios Motakis (3):
vfio: platform: add device properties skeleton and user API
vfio: platform: access device property as a list of strings
vfio: platform: return device properties as arrays of unsigned
integers

 drivers/vfio/platform/Makefile                |   3 +-
 drivers/vfio/platform/properties.c            | 162 ++++++++++++++++++++++++++
 drivers/vfio/platform/vfio_platform_common.c  |  35 ++++++
 drivers/vfio/platform/vfio_platform_private.h |   7 ++
 include/uapi/linux/vfio.h                     |  26 +++++
 5 files changed, 232 insertions(+), 1 deletion(-)
 create mode 100644 drivers/vfio/platform/properties.c

Quoted 8 lines · Eric Auger

Hi Baptiste, Antonios,

What are the plans wrt this series? I am currently integrating another QEMU VFIO platform devices where this series could be useful I think (Feb 2015). Do you intend to follow up and bring it upstream?

Alex, do you see some show-stoppers in this series or do you advise to simply follow-up?

I'm at a bit of a disadvantage not really knowing what types of properties a user will be able to retrieve here. The interface itself seems sort of like a game of Go Fish. Should the properties we're looking for be generally available via sysfs? The ioctl proposed needs some work to fit within the argsz/flags model that vfio typically uses. It's unclear what argsz vs length represents and defining the flags field as 'type' limits the future extensions of the ioctl. Thanks,

Alex

Quoted 61 lines · Antonios Motakis

Quoted 59 lines

This RFC's intention is to show what an interface to access device properties for the VFIO platform driver can look like. These properties can be from the device tree node describing the device, or ACPI properties in the future.

If a device property corresponding to a platform device bound by VFIO PLATFORM or VFIO AMBA is available, this patch series will allow the user to query for this information. This can be useful for userspace drivers to automatically query parameters related to the device.

Specifically for QEMU, reading the "compatible" property of the device tree node could be of use to find out what device is being assigned to the guest and handle appropriately a wider range of devices in the future, and to generate an appropriate device tree for the guest.

Older versions of this series where specifically targeted at device tree properties. This version has been reworked on top of Rafael J. Wysocki's uniform device properties API for device tree and ACPI devices. This will allow us to use the API in the future with devices described via ACPI.

This also means a kernel including the uniform device properties API is needed to apply these patches, in additon to the VFIO patches, e.g. branch pm+acpi-3.19-rc1 from https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/

The API to get the list of available properties and the device tree full_name have been removed. These probably don't serve an useful purpose, as the user of this API need to know anyway what properties are specific to the device he wants to access with VFIO. If we decide to reintroduce the list of properties in the future, the generic device properties API in the kernel will have to be extended accordingly.

A kernel with this series and all the dependencies applied can be pulled from branch vfio-device-properties-v3 from the repository:
https://github.com/virtualopensystems/linux-kvm-arm.git

Changes since v2:
- Reworked on top of Rafael J. Wysocki's uniform device properties API for device tree and ACPI
- Support for u64 array properties
- Removed API to get list of available properties and device tree full_name
Changes since v1:
- Updated for VFIO platform patch series v8:
VFIO AMBA devices now supported in addition to VFIO PLATFORM devices
- Refactored and cleaned up the code

Antonios Motakis (3):
vfio: platform: add device properties skeleton and user API
vfio: platform: access device property as a list of strings
vfio: platform: return device properties as arrays of unsigned
integers

 drivers/vfio/platform/Makefile                |   3 +-
 drivers/vfio/platform/properties.c            | 162 ++++++++++++++++++++++++++
 drivers/vfio/platform/vfio_platform_common.c  |  35 ++++++
 drivers/vfio/platform/vfio_platform_private.h |   7 ++
 include/uapi/linux/vfio.h                     |  26 +++++
 5 files changed, 232 insertions(+), 1 deletion(-)
 create mode 100644 drivers/vfio/platform/properties.c

Hi Alex,

Quoted 10 lines · Alex Williamson

Quoted 8 lines · Eric Auger

Hi Baptiste, Antonios,

What are the plans wrt this series? I am currently integrating another QEMU VFIO platform devices where this series could be useful I think (Feb 2015). Do you intend to follow up and bring it upstream?

Alex, do you see some show-stoppers in this series or do you advise to simply follow-up?

Quoted 7 lines

I'm at a bit of a disadvantage not really knowing what types of properties a user will be able to retrieve here. The interface itself seems sort of like a game of Go Fish. Should the properties we're looking for be generally available via sysfs? The ioctl proposed needs some work to fit within the argsz/flags model that vfio typically uses. It's unclear what argsz vs length represents and defining the flags field as 'type' limits the future extensions of the ioctl. Thanks,

The properties that I need can be found in /proc/device-tree too. They are of different types, with void cell value, with string cell values(single & multiple), with integer cell value(s), array ...

The aim is to be able to assign a highly configurable platform device to a guest, read some property values on host and write the same values in guest dt node.

Hi Eric,

Quoted 24 lines · Eric Auger

Hi Alex,

Quoted 10 lines · Alex Williamson

Quoted 8 lines · Eric Auger

Hi Baptiste, Antonios,

What are the plans wrt this series? I am currently integrating another QEMU VFIO platform devices where this series could be useful I think (Feb 2015). Do you intend to follow up and bring it upstream?

Alex, do you see some show-stoppers in this series or do you advise to simply follow-up?

Quoted 7 lines

I'm at a bit of a disadvantage not really knowing what types of properties a user will be able to retrieve here. The interface itself seems sort of like a game of Go Fish. Should the properties we're looking for be generally available via sysfs? The ioctl proposed needs some work to fit within the argsz/flags model that vfio typically uses. It's unclear what argsz vs length represents and defining the flags field as 'type' limits the future extensions of the ioctl. Thanks,

The properties that I need can be found in /proc/device-tree too. They are of different types, with void cell value, with string cell values(single & multiple), with integer cell value(s), array ...

Quoted 4 lines

The aim is to be able to assign a highly configurable platform device to a guest, read some property values on host and write the same values in guest dt node.

Can you reiterate why QEMU and VFIO don't already have the information necessary to setup resources and present a DT to the guest that the guest can use?

In any case, using /proc/device-tree seems brittle to me.

-Christoffer

Hi Christoffer,

Quoted 27 lines · Christoffer Dall

Hi Eric,

Quoted 24 lines · Eric Auger

Hi Alex,

Quoted 10 lines · Alex Williamson

Quoted 8 lines · Eric Auger

Hi Baptiste, Antonios,

What are the plans wrt this series? I am currently integrating another QEMU VFIO platform devices where this series could be useful I think (Feb 2015). Do you intend to follow up and bring it upstream?

Alex, do you see some show-stoppers in this series or do you advise to simply follow-up?

Quoted 7 lines

I'm at a bit of a disadvantage not really knowing what types of properties a user will be able to retrieve here. The interface itself seems sort of like a game of Go Fish. Should the properties we're looking for be generally available via sysfs? The ioctl proposed needs some work to fit within the argsz/flags model that vfio typically uses. It's unclear what argsz vs length represents and defining the flags field as 'type' limits the future extensions of the ioctl. Thanks,

The properties that I need can be found in /proc/device-tree too. They are of different types, with void cell value, with string cell values(single & multiple), with integer cell value(s), array ...

Quoted 7 lines

Quoted 4 lines

The aim is to be able to assign a highly configurable platform device to a guest, read some property values on host and write the same values in guest dt node.

Can you reiterate why QEMU and VFIO don't already have the information necessary to setup resources and present a DT to the guest that the guest can use?

A vfio-platform driver was bound to the passthrough'ed device. QEMU current knows the compat string of the device and the node's name and that's it.

The VFIO platform driver currently does not allow to return device specific information. It just returns generic info such as resource info. The driver is HW agnostic.

The QEMU VFIO device should be able to check some characteristics of the host device tree. Typically if the host node does not comply with some constraints it may not be possible to assign the device.

We do not want the QEMU end-user to have in-depth knowledge of the HW so passing the info in the QEMU command line does not sound to be the good solution.

As you mentioned /proc/device-tree depends on kernel option. I am able to find the properties in sysfs too but can we systematically rely on sysfs (CONFIG_SYSFS)? Also I would have expected the values to be human readable but they are not. Currently investigating open/read from qemu but is better than an ioctl API? ...

Quoted 54 lines · Eric Auger

Hi Christoffer,

Quoted 27 lines · Christoffer Dall

Hi Eric,

Quoted 24 lines · Eric Auger

Hi Alex,

Quoted 10 lines · Alex Williamson

Quoted 8 lines · Eric Auger

Hi Baptiste, Antonios,

What are the plans wrt this series? I am currently integrating another QEMU VFIO platform devices where this series could be useful I think (Feb 2015). Do you intend to follow up and bring it upstream?

Alex, do you see some show-stoppers in this series or do you advise to simply follow-up?

Quoted 7 lines

I'm at a bit of a disadvantage not really knowing what types of properties a user will be able to retrieve here. The interface itself seems sort of like a game of Go Fish. Should the properties we're looking for be generally available via sysfs? The ioctl proposed needs some work to fit within the argsz/flags model that vfio typically uses. It's unclear what argsz vs length represents and defining the flags field as 'type' limits the future extensions of the ioctl. Thanks,

The properties that I need can be found in /proc/device-tree too. They are of different types, with void cell value, with string cell values(single & multiple), with integer cell value(s), array ...

Quoted 7 lines

Quoted 4 lines

The aim is to be able to assign a highly configurable platform device to a guest, read some property values on host and write the same values in guest dt node.

Can you reiterate why QEMU and VFIO don't already have the information necessary to setup resources and present a DT to the guest that the guest can use?

A vfio-platform driver was bound to the passthrough'ed device. QEMU current knows the compat string of the device and the node's name and that's it.

The VFIO platform driver currently does not allow to return device specific information. It just returns generic info such as resource info. The driver is HW agnostic.

The QEMU VFIO device should be able to check some characteristics of the host device tree. Typically if the host node does not comply with some constraints it may not be possible to assign the device.

We do not want the QEMU end-user to have in-depth knowledge of the HW so passing the info in the QEMU command line does not sound to be the good solution.

Quoted 6 lines

As you mentioned /proc/device-tree depends on kernel option. I am able to find the properties in sysfs too but can we systematically rely on sysfs (CONFIG_SYSFS)? Also I would have expected the values to be human readable but they are not. Currently investigating open/read from qemu but is better than an ioctl API? ...

Yeah it does, but I thought we originally planned that the driver for a specific platform device in QEMU should know these details,

simply have to add code for each supported device, instead of trying to solve this generically. (It was never the user who should supply it on the command line). But perhaps we moved on from our original idea?

I think relying on sysfs is probably reasonable, but I'm really not an expert in the right ways here.

Thanks,
-Christoffer

Quoted 21 lines

Quoted 21 lines

Quoted 3 lines

Can you reiterate why QEMU and VFIO don't already have the information necessary to setup resources and present a DT to the guest that the guest can use?

A vfio-platform driver was bound to the passthrough'ed device. QEMU current knows the compat string of the device and the node's name and that's it.

The VFIO platform driver currently does not allow to return device specific information. It just returns generic info such as resource info. The driver is HW agnostic.

The QEMU VFIO device should be able to check some characteristics of the host device tree. Typically if the host node does not comply with some constraints it may not be possible to assign the device.

We do not want the QEMU end-user to have in-depth knowledge of the HW so passing the info in the QEMU command line does not sound to be the good solution.

Quoted 8 lines

Quoted 6 lines

As you mentioned /proc/device-tree depends on kernel option. I am able to find the properties in sysfs too but can we systematically rely on sysfs (CONFIG_SYSFS)? Also I would have expected the values to be human readable but they are not. Currently investigating open/read from qemu but is better than an ioctl API? ...

Yeah it does, but I thought we originally planned that the driver for a specific platform device in QEMU should know these details,

Yes that's the objective to put this intelligence in the QEMU VFIO device or more precisely in the associated function that builds its guest dt node.

Let's take an example. Assuming an xgmac supports different speeds, you need to set those on guest. Either you put arbitrary values or you reuse the values that were set on host. Typically some values may not be supported by the HW.

Idea of genericity was ruled out indeed meaning each device needs to have a specialized QEMU VFIO device and an associated dt node creation function. Now this does not prevent from exploiting host dt information. Does that make sense?

Hi Eric,

On Tue, Sep 01, 2015 at 09:31:56AM +0200, Eric Auger wrote:

[...]

Quoted 29 lines

Quoted 21 lines

Quoted 21 lines

Quoted 3 lines

Can you reiterate why QEMU and VFIO don't already have the information necessary to setup resources and present a DT to the guest that the guest can use?

A vfio-platform driver was bound to the passthrough'ed device. QEMU current knows the compat string of the device and the node's name and that's it.

The VFIO platform driver currently does not allow to return device specific information. It just returns generic info such as resource info. The driver is HW agnostic.

The QEMU VFIO device should be able to check some characteristics of the host device tree. Typically if the host node does not comply with some constraints it may not be possible to assign the device.

We do not want the QEMU end-user to have in-depth knowledge of the HW so passing the info in the QEMU command line does not sound to be the good solution.

Quoted 8 lines

Quoted 6 lines

As you mentioned /proc/device-tree depends on kernel option. I am able to find the properties in sysfs too but can we systematically rely on sysfs (CONFIG_SYSFS)? Also I would have expected the values to be human readable but they are not. Currently investigating open/read from qemu but is better than an ioctl API? ...

Yeah it does, but I thought we originally planned that the driver for a specific platform device in QEMU should know these details,

Quoted 9 lines

Yes that's the objective to put this intelligence in the QEMU VFIO device or more precisely in the associated function that builds its guest dt node.

Let's take an example. Assuming an xgmac supports different speeds, you need to set those on guest. Either you put arbitrary values or you reuse the values that were set on host. Typically some values may not be supported by the HW.

I see. I'm no expert here, but I could imagine that drivers could overwrite some things in the DT or do some advanced probing of the hardware which is then only exported in the sysfs and not the DT, so I would go the sysfs approach myself.

Quoted 5 lines

Idea of genericity was ruled out indeed meaning each device needs to have a specialized QEMU VFIO device and an associated dt node creation function. Now this does not prevent from exploiting host dt information. Does that make sense?

Yes, thanks for the explanation.

-Christoffer

- the device directory can be somewhere in /sys/devices/platform, ie. can be in sub-directories. The first difficulty is to locate it. Do you know any C routing doing find-file matching a file name pattern? Didn't find any in qemu, nor in glib.

- I currently prototype this functionality using popen + find. That works but relies on "find" executable availability. Is it a valid assumption?

Am 01.09.2015 um 17:29 schrieb Eric Auger <[email protected]>:

Dear all,

I am currently investigating the usage of sysfs to retrieve info from the host device tree to build guest dt node for assigned devices (just to explain a bit of context for Peter & Alex added in cc). For more complex devices we could typically copy host settings on guest side (mac @, various speeds, functional modes, ...).

This follows the "Re: [RFC PATCH v3 0/3] vfio: platform: return device properties for a platform device" thread.

I have some questions:

- the device directory can be somewhere in /sys/devices/platform, ie. can be in sub-directories. The first difficulty is to locate it. Do you know any C routing doing find-file matching a file name pattern? Didn't find any in qemu, nor in glib.

- I currently prototype this functionality using popen + find. That works but relies on "find" executable availability. Is it a valid assumption?

- I would need to build various utility functions such as read_u32_array_prop(char *path, const char *prop_name,

                              uint32_t *props, uint32 num)

path being the of_node directory path, prop_name being the name of the property to get the value; this for each type of property I need to fetch and assign to the guest ... Is it the right direction?

Putting things on kernel - VOSYS approach - and exposing new VFIO IOTCL enable to use std kernel APIs and remove the problem of finding data on the fs ...

Please advise on the direction to follow, continue exploring the sysfs method or revert to VOSYS approach?

Thank you in advance

Best Regards

Eric

Quoted 56 lines · Christoffer Dall

Hi Eric,

On Tue, Sep 01, 2015 at 09:31:56AM +0200, Eric Auger wrote:

[...]

Quoted 28 lines

Quoted 21 lines

Quoted 21 lines

Quoted 3 lines

Can you reiterate why QEMU and VFIO don't already have the information necessary to setup resources and present a DT to the guest that the guest can use?

A vfio-platform driver was bound to the passthrough'ed device. QEMU current knows the compat string of the device and the node's name and that's it.

The VFIO platform driver currently does not allow to return device specific information. It just returns generic info such as resource info. The driver is HW agnostic.

The QEMU VFIO device should be able to check some characteristics of the host device tree. Typically if the host node does not comply with some constraints it may not be possible to assign the device.

We do not want the QEMU end-user to have in-depth knowledge of the HW so passing the info in the QEMU command line does not sound to be the good solution.

Quoted 7 lines

Quoted 5 lines

As you mentioned /proc/device-tree depends on kernel option. I am able to find the properties in sysfs too but can we systematically rely on sysfs (CONFIG_SYSFS)? Also I would have expected the values to be human readable but they are not. Currently investigating open/read from qemu but is better than an ioctl API? ...

Yeah it does, but I thought we originally planned that the driver for a specific platform device in QEMU should know these details,

Quoted 8 lines

Yes that's the objective to put this intelligence in the QEMU VFIO device or more precisely in the associated function that builds its guest dt node.

Let's take an example. Assuming an xgmac supports different speeds, you need to set those on guest. Either you put arbitrary values or you reuse the values that were set on host. Typically some values may not be supported by the HW.

I see. I'm no expert here, but I could imagine that drivers could overwrite some things in the DT or do some advanced probing of the hardware which is then only exported in the sysfs and not the DT, so I would go the sysfs approach myself.

Quoted 4 lines

Idea of genericity was ruled out indeed meaning each device needs to have a specialized QEMU VFIO device and an associated dt node creation function. Now this does not prevent from exploiting host dt information. Does that make sense?

Yes, thanks for the explanation.

-Christoffer

Quoted 15 lines

Am 01.09.2015 um 17:29 schrieb Eric Auger <[email protected]>:

Dear all,

I am currently investigating the usage of sysfs to retrieve info from the host device tree to build guest dt node for assigned devices (just to explain a bit of context for Peter & Alex added in cc). For more complex devices we could typically copy host settings on guest side (mac @, various speeds, functional modes, ...).

This follows the "Re: [RFC PATCH v3 0/3] vfio: platform: return device properties for a platform device" thread.

Quoted 6 lines

I have some questions:

- the device directory can be somewhere in /sys/devices/platform, ie. can be in sub-directories. The first difficulty is to locate it. Do you know any C routing doing find-file matching a file name pattern? Didn't find any in qemu, nor in glib.

Best path imho is to have the vfio fd expose its path via an ioctl. Didn't we have that?

Quoted 5 lines

- I currently prototype this functionality using popen + find. That works but relies on "find" executable availability. Is it a valid assumption?

No :)

Quoted 8 lines

- I would need to build various utility functions such as read_u32_array_prop(char *path, const char *prop_name,

                              uint32_t *props, uint32 num)

path being the of_node directory path, prop_name being the name of the property to get the value; this for each type of property I need to fetch and assign to the guest ... Is it the right direction?

I don't know yet. Start with very specific needs for very specific devices first, create a list for your use case. Then go through each property and see whether you really need to get it from the host and how many there really are.

Alex

Quoted 73 lines

Putting things on kernel - VOSYS approach - and exposing new VFIO IOTCL enable to use std kernel APIs and remove the problem of finding data on the fs ...

Please advise on the direction to follow, continue exploring the sysfs method or revert to VOSYS approach?

Thank you in advance

Best Regards

Eric

Quoted 56 lines · Christoffer Dall

Hi Eric,

On Tue, Sep 01, 2015 at 09:31:56AM +0200, Eric Auger wrote:

[...]

Quoted 28 lines

Quoted 21 lines

Quoted 21 lines

Quoted 3 lines

Can you reiterate why QEMU and VFIO don't already have the information necessary to setup resources and present a DT to the guest that the guest can use?

A vfio-platform driver was bound to the passthrough'ed device. QEMU current knows the compat string of the device and the node's name and that's it.

The VFIO platform driver currently does not allow to return device specific information. It just returns generic info such as resource info. The driver is HW agnostic.

The QEMU VFIO device should be able to check some characteristics of the host device tree. Typically if the host node does not comply with some constraints it may not be possible to assign the device.

We do not want the QEMU end-user to have in-depth knowledge of the HW so passing the info in the QEMU command line does not sound to be the good solution.

Quoted 7 lines

Quoted 5 lines

As you mentioned /proc/device-tree depends on kernel option. I am able to find the properties in sysfs too but can we systematically rely on sysfs (CONFIG_SYSFS)? Also I would have expected the values to be human readable but they are not. Currently investigating open/read from qemu but is better than an ioctl API? ...

Yeah it does, but I thought we originally planned that the driver for a specific platform device in QEMU should know these details,

Quoted 8 lines

Yes that's the objective to put this intelligence in the QEMU VFIO device or more precisely in the associated function that builds its guest dt node.

Let's take an example. Assuming an xgmac supports different speeds, you need to set those on guest. Either you put arbitrary values or you reuse the values that were set on host. Typically some values may not be supported by the HW.

I see. I'm no expert here, but I could imagine that drivers could overwrite some things in the DT or do some advanced probing of the hardware which is then only exported in the sysfs and not the DT, so I would go the sysfs approach myself.

Quoted 4 lines

Idea of genericity was ruled out indeed meaning each device needs to have a specialized QEMU VFIO device and an associated dt node creation function. Now this does not prevent from exploiting host dt information. Does that make sense?

Yes, thanks for the explanation.

-Christoffer

Hi Eric,

On Tue, Sep 01, 2015 at 09:31:56AM +0200, Eric Auger wrote:

[...]

Quoted 29 lines

Quoted 21 lines

Quoted 21 lines

Quoted 3 lines

Can you reiterate why QEMU and VFIO don't already have the information necessary to setup resources and present a DT to the guest that the guest can use?

A vfio-platform driver was bound to the passthrough'ed device. QEMU current knows the compat string of the device and the node's name and that's it.

The VFIO platform driver currently does not allow to return device specific information. It just returns generic info such as resource info. The driver is HW agnostic.

The QEMU VFIO device should be able to check some characteristics of the host device tree. Typically if the host node does not comply with some constraints it may not be possible to assign the device.

We do not want the QEMU end-user to have in-depth knowledge of the HW so passing the info in the QEMU command line does not sound to be the good solution.

Quoted 8 lines

Quoted 6 lines

As you mentioned /proc/device-tree depends on kernel option. I am able to find the properties in sysfs too but can we systematically rely on sysfs (CONFIG_SYSFS)? Also I would have expected the values to be human readable but they are not. Currently investigating open/read from qemu but is better than an ioctl API? ...

Yeah it does, but I thought we originally planned that the driver for a specific platform device in QEMU should know these details,

Quoted 9 lines

Yes that's the objective to put this intelligence in the QEMU VFIO device or more precisely in the associated function that builds its guest dt node.

Let's take an example. Assuming an xgmac supports different speeds, you need to set those on guest. Either you put arbitrary values or you reuse the values that were set on host. Typically some values may not be supported by the HW.

I see. I'm no expert here, but I could imagine that drivers could overwrite some things in the DT or do some advanced probing of the hardware which is then only exported in the sysfs and not the DT, so I would go the sysfs approach myself.

Quoted 5 lines

Idea of genericity was ruled out indeed meaning each device needs to have a specialized QEMU VFIO device and an associated dt node creation function. Now this does not prevent from exploiting host dt information. Does that make sense?

Yes, thanks for the explanation.

-Christoffer

Hi everyone,

The usefullness of this patch has already been discussed during the
first releases (http://lists.linuxfoundation.org/pipermail/iommu/2014-August/009586.html).
I underline the fact that it avoids implementing the logic on the
userspace program, as VFIO can be used for many usage (userspace
drivers and device assignment).

If you're interested in the implementation on the userspace side, an RFC has been suggested for QEMU:
http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01211.html

Quoted 58 lines · Christoffer Dall

Hi Eric,

On Tue, Sep 01, 2015 at 09:31:56AM +0200, Eric Auger wrote:

[...]

Quoted 29 lines

Quoted 21 lines

Quoted 21 lines

Quoted 3 lines

Can you reiterate why QEMU and VFIO don't already have the information necessary to setup resources and present a DT to the guest that the guest can use?

A vfio-platform driver was bound to the passthrough'ed device. QEMU current knows the compat string of the device and the node's name and that's it.

The VFIO platform driver currently does not allow to return device specific information. It just returns generic info such as resource info. The driver is HW agnostic.

The QEMU VFIO device should be able to check some characteristics of the host device tree. Typically if the host node does not comply with some constraints it may not be possible to assign the device.

We do not want the QEMU end-user to have in-depth knowledge of the HW so passing the info in the QEMU command line does not sound to be the good solution.

Quoted 8 lines

Quoted 6 lines

As you mentioned /proc/device-tree depends on kernel option. I am able to find the properties in sysfs too but can we systematically rely on sysfs (CONFIG_SYSFS)? Also I would have expected the values to be human readable but they are not. Currently investigating open/read from qemu but is better than an ioctl API? ...

Yeah it does, but I thought we originally planned that the driver for a specific platform device in QEMU should know these details,

Quoted 9 lines

Yes that's the objective to put this intelligence in the QEMU VFIO device or more precisely in the associated function that builds its guest dt node.

Let's take an example. Assuming an xgmac supports different speeds, you need to set those on guest. Either you put arbitrary values or you reuse the values that were set on host. Typically some values may not be supported by the HW.

I see. I'm no expert here, but I could imagine that drivers could overwrite some things in the DT or do some advanced probing of the hardware which is then only exported in the sysfs and not the DT, so I would go the sysfs approach myself.

Quoted 5 lines

Idea of genericity was ruled out indeed meaning each device needs to have a specialized QEMU VFIO device and an associated dt node creation function. Now this does not prevent from exploiting host dt information. Does that make sense?

Yes, thanks for the explanation.

-Christoffer

Quoted 11 lines · Baptiste Reynal

Hi everyone,

The usefullness of this patch has already been discussed during the
first releases (http://lists.linuxfoundation.org/pipermail/iommu/2014-August/009586.html).
I underline the fact that it avoids implementing the logic on the
userspace program, as VFIO can be used for many usage (userspace
drivers and device assignment).

If you're interested in the implementation on the userspace side, an RFC has been suggested for QEMU:
http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01211.html

This one-year-old discussion is hardly exhaustive.

I think you missed the gist of the question for Eric a bit as well.

One important question for me is whether seeing the host DT is always sufficient or if the kernel and physical device driver can have more information about the device and its configuration which userspace may need, which cannot be directly read in the DT (for example because the driver has initialized the device in a specific way). My point is, it's really not about DT-specific things (what if you used ACPI?), but it's about retrieving properties of a device and its configuration from userspace.

Have we thought about the possible ways to achieve this and weight one option against the other?

-Christoffer

Quoted 61 lines

Quoted 58 lines · Christoffer Dall

Hi Eric,

On Tue, Sep 01, 2015 at 09:31:56AM +0200, Eric Auger wrote:

[...]

Quoted 29 lines

Quoted 21 lines

Quoted 21 lines

Quoted 3 lines

Can you reiterate why QEMU and VFIO don't already have the information necessary to setup resources and present a DT to the guest that the guest can use?

A vfio-platform driver was bound to the passthrough'ed device. QEMU current knows the compat string of the device and the node's name and that's it.

The VFIO platform driver currently does not allow to return device specific information. It just returns generic info such as resource info. The driver is HW agnostic.

The QEMU VFIO device should be able to check some characteristics of the host device tree. Typically if the host node does not comply with some constraints it may not be possible to assign the device.

We do not want the QEMU end-user to have in-depth knowledge of the HW so passing the info in the QEMU command line does not sound to be the good solution.

Quoted 8 lines

Quoted 6 lines

As you mentioned /proc/device-tree depends on kernel option. I am able to find the properties in sysfs too but can we systematically rely on sysfs (CONFIG_SYSFS)? Also I would have expected the values to be human readable but they are not. Currently investigating open/read from qemu but is better than an ioctl API? ...

Yeah it does, but I thought we originally planned that the driver for a specific platform device in QEMU should know these details,

Quoted 9 lines

Yes that's the objective to put this intelligence in the QEMU VFIO device or more precisely in the associated function that builds its guest dt node.

Let's take an example. Assuming an xgmac supports different speeds, you need to set those on guest. Either you put arbitrary values or you reuse the values that were set on host. Typically some values may not be supported by the HW.

I see. I'm no expert here, but I could imagine that drivers could overwrite some things in the DT or do some advanced probing of the hardware which is then only exported in the sysfs and not the DT, so I would go the sysfs approach myself.

Quoted 5 lines

Idea of genericity was ruled out indeed meaning each device needs to have a specialized QEMU VFIO device and an associated dt node creation function. Now this does not prevent from exploiting host dt information. Does that make sense?

Yes, thanks for the explanation.

-Christoffer

Quoted 26 lines · Christoffer Dall

Quoted 11 lines · Baptiste Reynal

Hi everyone,

The usefullness of this patch has already been discussed during the
first releases (http://lists.linuxfoundation.org/pipermail/iommu/2014-August/009586.html).
I underline the fact that it avoids implementing the logic on the
userspace program, as VFIO can be used for many usage (userspace
drivers and device assignment).

If you're interested in the implementation on the userspace side, an RFC has been suggested for QEMU:
http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01211.html

This one-year-old discussion is hardly exhaustive.

I think you missed the gist of the question for Eric a bit as well.

One important question for me is whether seeing the host DT is always sufficient or if the kernel and physical device driver can have more information about the device and its configuration which userspace may need, which cannot be directly read in the DT (for example because the driver has initialized the device in a specific way). My point is, it's really not about DT-specific things (what if you used ACPI?), but it's about retrieving properties of a device and its configuration from userspace.

Quoted 2 lines

Have we thought about the possible ways to achieve this and weight one option against the other?

Problem is that now we only have a very few platform devices behind an IOMMU, so we don't have the visibility to know if such a case will occur. With the current use cases, the interface seems to be sufficient.

By using IOCTL, we can always change the implementation later without any change on the userspace.

Do you think we can valid the API, then if such a case occurs (when the device informations changes between the device tree and the running state) we can change the kernel implementation ?

Quoted 28 lines · Baptiste Reynal

Quoted 26 lines · Christoffer Dall

Quoted 11 lines · Baptiste Reynal

Hi everyone,

The usefullness of this patch has already been discussed during the
first releases (http://lists.linuxfoundation.org/pipermail/iommu/2014-August/009586.html).
I underline the fact that it avoids implementing the logic on the
userspace program, as VFIO can be used for many usage (userspace
drivers and device assignment).

If you're interested in the implementation on the userspace side, an RFC has been suggested for QEMU:
http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01211.html

This one-year-old discussion is hardly exhaustive.

I think you missed the gist of the question for Eric a bit as well.

One important question for me is whether seeing the host DT is always sufficient or if the kernel and physical device driver can have more information about the device and its configuration which userspace may need, which cannot be directly read in the DT (for example because the driver has initialized the device in a specific way). My point is, it's really not about DT-specific things (what if you used ACPI?), but it's about retrieving properties of a device and its configuration from userspace.

Quoted 7 lines

Quoted 2 lines

Have we thought about the possible ways to achieve this and weight one option against the other?

Problem is that now we only have a very few platform devices behind an IOMMU, so we don't have the visibility to know if such a case will occur. With the current use cases, the interface seems to be sufficient.

Ideally we can think about future use cases based on the experience of people in the community and come up with a solution considering future use cases.

Quoted 2 lines

By using IOCTL, we can always change the implementation later without any change on the userspace.

Can you be more concrete with what you mean here?

Quoted 5 lines

Do you think we can valid the API, then if such a case occurs (when the device informations changes between the device tree and the running state) we can change the kernel implementation ?

Sorry, I don't understand this paragraph.

-Christoffer

Quoted 44 lines · Christoffer Dall

Quoted 28 lines · Baptiste Reynal

Quoted 26 lines · Christoffer Dall

Quoted 11 lines · Baptiste Reynal

Hi everyone,

The usefullness of this patch has already been discussed during the
first releases (http://lists.linuxfoundation.org/pipermail/iommu/2014-August/009586.html).
I underline the fact that it avoids implementing the logic on the
userspace program, as VFIO can be used for many usage (userspace
drivers and device assignment).

If you're interested in the implementation on the userspace side, an RFC has been suggested for QEMU:
http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01211.html

This one-year-old discussion is hardly exhaustive.

I think you missed the gist of the question for Eric a bit as well.

One important question for me is whether seeing the host DT is always sufficient or if the kernel and physical device driver can have more information about the device and its configuration which userspace may need, which cannot be directly read in the DT (for example because the driver has initialized the device in a specific way). My point is, it's really not about DT-specific things (what if you used ACPI?), but it's about retrieving properties of a device and its configuration from userspace.

Quoted 7 lines

Quoted 2 lines

Have we thought about the possible ways to achieve this and weight one option against the other?

Problem is that now we only have a very few platform devices behind an IOMMU, so we don't have the visibility to know if such a case will occur. With the current use cases, the interface seems to be sufficient.

Ideally we can think about future use cases based on the experience of people in the community and come up with a solution considering future use cases.

Quoted 2 lines

By using IOCTL, we can always change the implementation later without any change on the userspace.

Quoted 2 lines

Can you be more concrete with what you mean here?

By using an IOCTL, we define an API that allows to retrieve device properties from userspace. The way it is retrieved is handled by the kernel (For example for now if OF is unavailable, the kernel will retrieve the property using ACPI) and is totally transparent from the userspace point of view.

My point is that we can go with the current naive implementation for now, and we might extend it later according to the needs of future devices, without changing anything from the userspace point of view.

Quoted 46 lines · Baptiste Reynal

Quoted 44 lines · Christoffer Dall

Quoted 28 lines · Baptiste Reynal

Quoted 26 lines · Christoffer Dall

Quoted 11 lines · Baptiste Reynal

Hi everyone,

The usefullness of this patch has already been discussed during the
first releases (http://lists.linuxfoundation.org/pipermail/iommu/2014-August/009586.html).
I underline the fact that it avoids implementing the logic on the
userspace program, as VFIO can be used for many usage (userspace
drivers and device assignment).

If you're interested in the implementation on the userspace side, an RFC has been suggested for QEMU:
http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01211.html

This one-year-old discussion is hardly exhaustive.

I think you missed the gist of the question for Eric a bit as well.

One important question for me is whether seeing the host DT is always sufficient or if the kernel and physical device driver can have more information about the device and its configuration which userspace may need, which cannot be directly read in the DT (for example because the driver has initialized the device in a specific way). My point is, it's really not about DT-specific things (what if you used ACPI?), but it's about retrieving properties of a device and its configuration from userspace.

Quoted 7 lines

Quoted 2 lines

Have we thought about the possible ways to achieve this and weight one option against the other?

Problem is that now we only have a very few platform devices behind an IOMMU, so we don't have the visibility to know if such a case will occur. With the current use cases, the interface seems to be sufficient.

Ideally we can think about future use cases based on the experience of people in the community and come up with a solution considering future use cases.

Quoted 2 lines

By using IOCTL, we can always change the implementation later without any change on the userspace.

Quoted 8 lines

Quoted 2 lines

Can you be more concrete with what you mean here?

By using an IOCTL, we define an API that allows to retrieve device properties from userspace. The way it is retrieved is handled by the kernel (For example for now if OF is unavailable, the kernel will retrieve the property using ACPI) and is totally transparent from the userspace point of view.

ok, I thought that this series was targeting device tree specifically, but I see that you changed this approach in v3.

Quoted 1 line

Quoted 4 lines

My point is that we can go with the current naive implementation for now, and we might extend it later according to the needs of future devices, without changing anything from the userspace point of view.

fair enough.

Is this series exporting properties not already exported through sysfs?

-Christoffer

Quoted 37 lines · Christoffer Dall

Quoted 28 lines · Baptiste Reynal

Quoted 26 lines · Christoffer Dall

Quoted 11 lines · Baptiste Reynal

Hi everyone,

The usefullness of this patch has already been discussed during the
first releases (http://lists.linuxfoundation.org/pipermail/iommu/2014-August/009586.html).
I underline the fact that it avoids implementing the logic on the
userspace program, as VFIO can be used for many usage (userspace
drivers and device assignment).

If you're interested in the implementation on the userspace side, an RFC has been suggested for QEMU:
http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01211.html

This one-year-old discussion is hardly exhaustive.

I think you missed the gist of the question for Eric a bit as well.

One important question for me is whether seeing the host DT is always sufficient or if the kernel and physical device driver can have more information about the device and its configuration which userspace may need, which cannot be directly read in the DT (for example because the driver has initialized the device in a specific way). My point is, it's really not about DT-specific things (what if you used ACPI?), but it's about retrieving properties of a device and its configuration from userspace.

Quoted 7 lines

Quoted 2 lines

Have we thought about the possible ways to achieve this and weight one option against the other?

Problem is that now we only have a very few platform devices behind an IOMMU, so we don't have the visibility to know if such a case will occur. With the current use cases, the interface seems to be sufficient.

Quoted 9 lines

Ideally we can think about future use cases based on the experience of people in the community and come up with a solution considering future use cases.

Quoted 2 lines

By using IOCTL, we can always change the implementation later without any change on the userspace.

Can you be more concrete with what you mean here?

By using an IOCTL, we define an API that allows to retrieve device properties from userspace. The way it is retrieved is handled by the kernel (For example for now if OF is unavailable, the kernel will retrieve the property using ACPI) and is totally transparent from the userspace point of view.

My point is that we can go with the current naive implementation for now, and we might extend it later according to the needs of future devices, without changing anything from the userspace point of view.

Quoted 55 lines · Baptiste Reynal

Quoted 37 lines · Christoffer Dall

Quoted 28 lines · Baptiste Reynal

Quoted 26 lines · Christoffer Dall

Quoted 11 lines · Baptiste Reynal

Hi everyone,

The usefullness of this patch has already been discussed during the
first releases (http://lists.linuxfoundation.org/pipermail/iommu/2014-August/009586.html).
I underline the fact that it avoids implementing the logic on the
userspace program, as VFIO can be used for many usage (userspace
drivers and device assignment).

If you're interested in the implementation on the userspace side, an RFC has been suggested for QEMU:
http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01211.html

This one-year-old discussion is hardly exhaustive.

I think you missed the gist of the question for Eric a bit as well.

One important question for me is whether seeing the host DT is always sufficient or if the kernel and physical device driver can have more information about the device and its configuration which userspace may need, which cannot be directly read in the DT (for example because the driver has initialized the device in a specific way). My point is, it's really not about DT-specific things (what if you used ACPI?), but it's about retrieving properties of a device and its configuration from userspace.

Quoted 7 lines

Quoted 2 lines

Have we thought about the possible ways to achieve this and weight one option against the other?

Problem is that now we only have a very few platform devices behind an IOMMU, so we don't have the visibility to know if such a case will occur. With the current use cases, the interface seems to be sufficient.

Quoted 9 lines

Ideally we can think about future use cases based on the experience of people in the community and come up with a solution considering future use cases.

Quoted 2 lines

By using IOCTL, we can always change the implementation later without any change on the userspace.

Can you be more concrete with what you mean here?

By using an IOCTL, we define an API that allows to retrieve device properties from userspace. The way it is retrieved is handled by the kernel (For example for now if OF is unavailable, the kernel will retrieve the property using ACPI) and is totally transparent from the userspace point of view.

Quoted 3 lines

My point is that we can go with the current naive implementation for now, and we might extend it later according to the needs of future devices, without changing anything from the userspace point of view.

I don't really like "ioctl" and "naive implementation" in the same thought. The ioctl itself needs to be well thought out for current and future needs, including independence from the source data type (OF/DT/ACPI/etc), proven that it's necessary, it's not redundant to existing interfaces, and vfio should be the one hosting it. Thanks,

Alex

Quoted 60 lines · Alex Williamson

Quoted 55 lines · Baptiste Reynal

Quoted 37 lines · Christoffer Dall

Quoted 28 lines · Baptiste Reynal

Quoted 26 lines · Christoffer Dall

Quoted 11 lines · Baptiste Reynal

Hi everyone,

The usefullness of this patch has already been discussed during the
first releases (http://lists.linuxfoundation.org/pipermail/iommu/2014-August/009586.html).
I underline the fact that it avoids implementing the logic on the
userspace program, as VFIO can be used for many usage (userspace
drivers and device assignment).

If you're interested in the implementation on the userspace side, an RFC has been suggested for QEMU:
http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01211.html

This one-year-old discussion is hardly exhaustive.

I think you missed the gist of the question for Eric a bit as well.

One important question for me is whether seeing the host DT is always sufficient or if the kernel and physical device driver can have more information about the device and its configuration which userspace may need, which cannot be directly read in the DT (for example because the driver has initialized the device in a specific way). My point is, it's really not about DT-specific things (what if you used ACPI?), but it's about retrieving properties of a device and its configuration from userspace.

Quoted 7 lines

Quoted 2 lines

Have we thought about the possible ways to achieve this and weight one option against the other?

Problem is that now we only have a very few platform devices behind an IOMMU, so we don't have the visibility to know if such a case will occur. With the current use cases, the interface seems to be sufficient.

Quoted 9 lines

Ideally we can think about future use cases based on the experience of people in the community and come up with a solution considering future use cases.

Quoted 2 lines

By using IOCTL, we can always change the implementation later without any change on the userspace.

Can you be more concrete with what you mean here?

By using an IOCTL, we define an API that allows to retrieve device properties from userspace. The way it is retrieved is handled by the kernel (For example for now if OF is unavailable, the kernel will retrieve the property using ACPI) and is totally transparent from the userspace point of view.

Quoted 3 lines

My point is that we can go with the current naive implementation for now, and we might extend it later according to the needs of future devices, without changing anything from the userspace point of view.

Quoted 6 lines

I don't really like "ioctl" and "naive implementation" in the same thought. The ioctl itself needs to be well thought out for current and future needs, including independence from the source data type (OF/DT/ACPI/etc), proven that it's necessary, it's not redundant to existing interfaces, and vfio should be the one hosting it. Thanks,

The word we used, naive, does not mean a bad implementation of the IOCTL interface but rather it was referring to the fact that at this moment we export 1-to-1 the information available in the device tree via sys or proc file system. So one could obtain the same result without such interface, however our implementation is aready independent from the source of such information, since OF and ACPI are supported already, and there will be no problem in extending the interface to support more.

Quoted 69 lines · Baptiste Reynal

Quoted 60 lines · Alex Williamson

Quoted 55 lines · Baptiste Reynal

Quoted 37 lines · Christoffer Dall

Quoted 28 lines · Baptiste Reynal

Quoted 26 lines · Christoffer Dall

Quoted 11 lines · Baptiste Reynal

Hi everyone,

The usefullness of this patch has already been discussed during the
first releases (http://lists.linuxfoundation.org/pipermail/iommu/2014-August/009586.html).
I underline the fact that it avoids implementing the logic on the
userspace program, as VFIO can be used for many usage (userspace
drivers and device assignment).

If you're interested in the implementation on the userspace side, an RFC has been suggested for QEMU:
http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01211.html

This one-year-old discussion is hardly exhaustive.

I think you missed the gist of the question for Eric a bit as well.

One important question for me is whether seeing the host DT is always sufficient or if the kernel and physical device driver can have more information about the device and its configuration which userspace may need, which cannot be directly read in the DT (for example because the driver has initialized the device in a specific way). My point is, it's really not about DT-specific things (what if you used ACPI?), but it's about retrieving properties of a device and its configuration from userspace.

Quoted 7 lines

Quoted 2 lines

Have we thought about the possible ways to achieve this and weight one option against the other?

Problem is that now we only have a very few platform devices behind an IOMMU, so we don't have the visibility to know if such a case will occur. With the current use cases, the interface seems to be sufficient.

Quoted 9 lines

Ideally we can think about future use cases based on the experience of people in the community and come up with a solution considering future use cases.

Quoted 2 lines

By using IOCTL, we can always change the implementation later without any change on the userspace.

Can you be more concrete with what you mean here?

By using an IOCTL, we define an API that allows to retrieve device properties from userspace. The way it is retrieved is handled by the kernel (For example for now if OF is unavailable, the kernel will retrieve the property using ACPI) and is totally transparent from the userspace point of view.

Quoted 3 lines

My point is that we can go with the current naive implementation for now, and we might extend it later according to the needs of future devices, without changing anything from the userspace point of view.

Quoted 6 lines

I don't really like "ioctl" and "naive implementation" in the same thought. The ioctl itself needs to be well thought out for current and future needs, including independence from the source data type (OF/DT/ACPI/etc), proven that it's necessary, it's not redundant to existing interfaces, and vfio should be the one hosting it. Thanks,

Quoted 9 lines

The word we used, naive, does not mean a bad implementation of the IOCTL interface but rather it was referring to the fact that at this moment we export 1-to-1 the information available in the device tree via sys or proc file system. So one could obtain the same result without such interface, however our implementation is aready independent from the source of such information, since OF and ACPI are supported already, and there will be no problem in extending the interface to support more.

I'm going to have to ask again then. Did you mean to say that these patches export the same information as you can obtain through sysfs?

Then what again is the rationale for adding this?

Is it not common practice for userspace tools to look in sysfs for device information?

Quoted 60 lines · Alex Williamson

Quoted 55 lines · Baptiste Reynal

Quoted 37 lines · Christoffer Dall

Quoted 28 lines · Baptiste Reynal

Quoted 26 lines · Christoffer Dall

Quoted 11 lines · Baptiste Reynal

Hi everyone,

The usefullness of this patch has already been discussed during the
first releases (http://lists.linuxfoundation.org/pipermail/iommu/2014-August/009586.html).
I underline the fact that it avoids implementing the logic on the
userspace program, as VFIO can be used for many usage (userspace
drivers and device assignment).

If you're interested in the implementation on the userspace side, an RFC has been suggested for QEMU:
http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01211.html

This one-year-old discussion is hardly exhaustive.

I think you missed the gist of the question for Eric a bit as well.

One important question for me is whether seeing the host DT is always sufficient or if the kernel and physical device driver can have more information about the device and its configuration which userspace may need, which cannot be directly read in the DT (for example because the driver has initialized the device in a specific way). My point is, it's really not about DT-specific things (what if you used ACPI?), but it's about retrieving properties of a device and its configuration from userspace.

Quoted 7 lines

Quoted 2 lines

Have we thought about the possible ways to achieve this and weight one option against the other?

Problem is that now we only have a very few platform devices behind an IOMMU, so we don't have the visibility to know if such a case will occur. With the current use cases, the interface seems to be sufficient.

Quoted 9 lines

Ideally we can think about future use cases based on the experience of people in the community and come up with a solution considering future use cases.

Quoted 2 lines

By using IOCTL, we can always change the implementation later without any change on the userspace.

Can you be more concrete with what you mean here?

By using an IOCTL, we define an API that allows to retrieve device properties from userspace. The way it is retrieved is handled by the kernel (For example for now if OF is unavailable, the kernel will retrieve the property using ACPI) and is totally transparent from the userspace point of view.

Quoted 3 lines

My point is that we can go with the current naive implementation for now, and we might extend it later according to the needs of future devices, without changing anything from the userspace point of view.

Quoted 6 lines

I don't really like "ioctl" and "naive implementation" in the same thought. The ioctl itself needs to be well thought out for current and future needs, including independence from the source data type (OF/DT/ACPI/etc), proven that it's necessary, it's not redundant to existing interfaces, and vfio should be the one hosting it. Thanks,

The word we used, naive, does not mean a bad implementation of the IOCTL interface but rather it was referring to the fact that at this moment we export 1-to-1 the information available in the device tree via sys or proc file system. So one could obtain the same result without such interface, however our implementation is aready independent from the source of such information, since OF and ACPI are supported already, and there will be no problem in extending the interface to support more.

The next release will take into account your comments about argsz and flags.

Regards,
Baptiste

Quoted 2 lines

Alex