vfio: platform: return device tree info for a platform device node
Subsystems (4)
v2 cover vfio: platform: return device tree info for a platform device node
This RFC's intention is to show what an interface to access device node properties for the VFIO platform driver can look like.
If a device tree node corresponding to a platform device bound by VFIO PLATFORM or VFIO AMBA is available, this patch series will allow the user to query the properties associated with this device node. This can be useful for userspace drivers to automatically query parameters related to the device.
An API to return data from a device's device tree has been proposed before on these lists. The API proposed here is slightly different.
Properties to parse from the device tree are not indexed by a numerical id. The host system doesn't guarantee any specific ordering for the available properties, or that those will remain the same; while this does not happen in practice, there is nothing from the host changing the device nodes during operation. For this reason in this RFC properties are accessed by property name.
The type of the property accessed must also be known by the user. Properties types implemented in this RFC:
- VFIO_DEVTREE_TYPE_STRINGS (strings sepparated by the null character)
- VFIO_DEVTREE_TYPE_U32
- VFIO_DEVTREE_TYPE_U16
- VFIO_DEVTREE_TYPE_U8
These can all be access by the ioctl VFIO_DEVICE_GET_DEVTREE_INFO. A new ioctl was preferred instead of shoehorning the functionality in VFIO_DEVICE_GET_INFO. The structure exchanged with userspace looks like this:
/**
* VFIO_DEVICE_GET_DEVTREE_INFO - _IOR(VFIO_TYPE, VFIO_BASE + 16,
* struct vfio_devtree_info)
*
* Retrieve information from the device's device tree, if available.
* Caller will initialize data[] with a single string with the requested
* devicetree property name, and type depending on whether a array of strings
* or an array of u32 values is expected. On success, data[] will be extended
* with the requested information, either as an array of u32, or with a list
* of strings sepparated by the NULL terminating character.
* Return: 0 on success, -errno on failure.
*/
struct vfio_devtree_info {
__u32 argsz;
__u32 type;#define VFIO_DEVTREE_PROP_LIST 0
#define VFIO_DEVTREE_TYPE_STRINGS 1
#define VFIO_DEVTREE_TYPE_U8 2
#define VFIO_DEVTREE_TYPE_U16 3
#define VFIO_DEVTREE_TYPE_U32 4 __u32 length; __u8 data[]; };
#define VFIO_DEVICE_GET_DEVTREE_INFO _IO(VFIO_TYPE, VFIO_BASE + 17)
The length of the property will be reported in length, so the user can reallocate the structure if the data does not fit the first time the call is used.
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.
TODOs:
- 64 bit values support
- We can consider to rebase this on the patch series by Rafael J. Wysocki:
"[PATCH v4 00/13] Add ACPI _DSD and unified device properties support" This would make 64 bit support more straightforward as it already includes the APIs we need for 64 bit OF values.
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 (4):
vfio: platform: add device tree info API and skeleton
vfio: platform: devtree: return available property names
vfio: platform: devtree: access property as a list of strings
vfio: platform: devtree: return arrays of u32, u16, or u8 data
drivers/vfio/platform/Makefile | 3 +- drivers/vfio/platform/devtree.c | 199 ++++++++++++++++++++++++++ drivers/vfio/platform/vfio_platform_common.c | 39 +++++ drivers/vfio/platform/vfio_platform_private.h | 6 + include/uapi/linux/vfio.h | 26 ++++ 5 files changed, 272 insertions(+), 1 deletion(-) create mode 100644 drivers/vfio/platform/devtree.c
Signature · 1 line
2.1.1
RFC PATCH v2 1/4 vfio: platform: add device tree info API and skeleton
This patch introduced the API to return device tree info about a PLATFORM device (if described by a device tree) 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_DEVTREE_INFO.
The proposed API allows to get a list of strings with available property names, and then allows to query each property. Note that the properties are not indexed numerically, so they are always accessed by property name. The user needs to know the data type of the property he is accessing.
--- drivers/vfio/platform/Makefile | 3 +- drivers/vfio/platform/devtree.c | 70 +++++++++++++++++++++++++++ drivers/vfio/platform/vfio_platform_common.c | 39 +++++++++++++++ drivers/vfio/platform/vfio_platform_private.h | 6 +++ include/uapi/linux/vfio.h | 26 ++++++++++ 5 files changed, 143 insertions(+), 1 deletion(-) create mode 100644 drivers/vfio/platform/devtree.c
drivers/vfio/platform/Makefile +2 -1
@@ -1,5 +1,6 @@ -vfio-platform-y := vfio_platform.o vfio_platform_common.o vfio_platform_irq.o +vfio-platform-y := vfio_platform.o vfio_platform_common.o vfio_platform_irq.o \ + devtree.o obj-$(CONFIG_VFIO_PLATFORM) += vfio-platform.o
drivers/vfio/platform/devtree.c new file +70 -0
70 lines not on this page · raw message
drivers/vfio/platform/vfio_platform_common.c +39 -0
@@ -24,6 +24,7 @@#include <linux/uaccess.h> #include <linux/vfio.h> #include <linux/io.h> +#include <linux/of.h> #include "vfio_platform_private.h"
@@ -244,6 +245,34 @@ static long vfio_platform_ioctl(void *device_data,return ret; + }else if (cmd ==VFIO_DEVICE_GET_DEVTREE_INFO ) { +struct vfio_devtree_info info; +void __user *datap; +unsigned long datasz; +int ret; + +if (!vdev->of_node) +return -EINVAL ; + + minsz = offsetofend(struct vfio_devtree_info, 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_devtree_info (vdev->of_node, 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 ;
@@ -486,6 +515,11 @@ int vfio_platform_probe_common(struct vfio_platform_device *vdev,return ret; } +/* get device tree node for info if available */ + vdev->of_node =of_node_get (dev->of_node); +if (vdev->of_node) + vdev->flags |=VFIO_DEVICE_FLAGS_DEVTREE ; +mutex_init (&vdev->igate);return 0 ;
@@ -500,6 +534,11 @@ int vfio_platform_remove_common(struct device *dev)if (!vdev)return -EINVAL ; +if (vdev->of_node) { +of_node_put (vdev->of_node); + vdev->of_node =NULL ; + } +iommu_group_put (dev->iommu_group);kfree (vdev);
drivers/vfio/platform/vfio_platform_private.h +6 -0
@@ -60,6 +60,7 @@ struct vfio_platform_device {void *opaque;const char *name;uint32_t flags; +struct device_node *of_node;/* callbacks to discover device resources */ struct resource * (*get_resource)(struct vfio_platform_device *vdev,int i);
@@ -77,4 +78,9 @@ extern int vfio_platform_set_irqs_ioctl(struct vfio_platform_device *vdev, uint32_t flags, unsigned index, unsigned start, unsigned count, void *data); +/* device tree info support in devtree.c */ +extern int vfio_platform_devtree_info (struct device_node *np, +uint32_t type,unsigned *lenp, +void __user *datap,unsigned long datasz); +#endif /* VFIO_PLATFORM_PRIVATE_H */
include/uapi/linux/vfio.h +26 -0
@@ -160,12 +160,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_DEVTREE (1 << 4)/* device tree metadata */ __u32 num_regions;/* Max region index + 1 */ __u32 num_irqs;/* Max IRQ index + 1 */ };#define VFIO_DEVICE_GET_INFO _IO(VFIO_TYPE, VFIO_BASE + 7)/** +* VFIO_DEVICE_GET_DEVTREE_INFO - _IOR(VFIO_TYPE, VFIO_BASE + 16, +* struct vfio_devtree_info) +* +* Retrieve information from the device's device tree, if available. +* Caller will initialize data[] with a single string with the requested +* devicetree property name, and type depending on whether a array of strings +* or an array of u32 values is expected. On success, data[] will be extended +* with the requested information, either as an array of u32, or with a list +* of strings sepparated by the NULL terminating character. +* Return: 0 on success, -errno on failure. +*/ +struct vfio_devtree_info { +__u32 argsz; +__u32 type; +#define VFIO_DEVTREE_PROP_LIST 0 +#define VFIO_DEVTREE_TYPE_STRINGS 1 +#define VFIO_DEVTREE_TYPE_U8 2 +#define VFIO_DEVTREE_TYPE_U16 3 +#define VFIO_DEVTREE_TYPE_U32 4 +__u32 length; +__u8 data[]; +}; +#define VFIO_DEVICE_GET_DEVTREE_INFO _IO(VFIO_TYPE, VFIO_BASE + 17) + +/** * VFIO_DEVICE_GET_REGION_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 8, * struct vfio_region_info) *
Signature · 1 line
2.1.1
RFC PATCH v2 2/4 vfio: platform: devtree: return available property names
In reply to Antonios MotakisThe available properties of a device are not indexed numerically, instead they are accessible by property name.
Passing type = VFIO_DEVTREE_PROP_LIST to VFIO_DEVICE_GET_DEVTREE_INFO, returns a list of strings with the available properties that the VFIO user can access.
--- drivers/vfio/platform/devtree.c | 37 ++++++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-)
drivers/vfio/platform/devtree.c +36 -1
@@ -7,7 +7,42 @@static int devtree_get_prop_list (struct device_node *np,unsigned *lenp,void __user *datap,unsigned long datasz) { -return -EINVAL ; +struct property *prop; +int len =0 , sz; +int ret =0 ; + +for_each_property_of_node (np, prop) { + sz =strlen (prop->name) +1 ; + +if (datasz < sz) { + ret = -EAGAIN ; +break ; + } + +if (copy_to_user (datap, prop->name, sz)) +return -EFAULT ; + + datap += sz; + datasz -= sz; + len += sz; + } + +/* if overflow occurs, calculate remaining length */ +while (prop) { + len +=strlen (prop->name) +1 ; + prop = prop->next; + } + +/* we expose the full_name in addition to the usual properties */ + len += sz =strlen ("full_name" ) +1 ; +if (datasz < sz) { + ret = -EAGAIN ; + }else if (copy_to_user (datap,"full_name" , sz)) +return -EFAULT ; + + *lenp = len; + +return ret; } static int devtree_get_strings(struct device_node *np,
Signature · 1 line
2.1.1
RFC PATCH v2 3/4 vfio: platform: devtree: access property as a list of strings
In reply to Antonios MotakisCertain device tree 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.
--- drivers/vfio/platform/devtree.c | 43 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-)
drivers/vfio/platform/devtree.c +42 -1
@@ -45,11 +45,52 @@ static int devtree_get_prop_list(struct device_node *np, unsigned *lenp,return ret; } +static int devtree_get_full_name (struct device_node *np,unsigned *lenp, +void __user *datap,unsigned long datasz) +{ +int len =strlen (np->full_name) +1 ; + +if (lenp) + *lenp = len; + +if (len > datasz) +return -EAGAIN ; + +if (copy_to_user (datap, np->full_name, len)) +return -EFAULT ; + +return 0 ; +} +static int devtree_get_strings (struct device_node *np,char *name,unsigned *lenp,void __user *datap,unsigned long datasz) { -return -EINVAL ; +struct property *prop; +int len; + + prop =of_find_property (np, name, &len); + +if (!prop) { +/* special case full_name as a property that is not on the fdt, +* but we wish to return to the user as it includes the full +* path of the device */ +if (!strcmp (name,"full_name" )) +return devtree_get_full_name (np, lenp, datap, datasz); +else +return -EINVAL ; + } + +if (lenp) + *lenp = len; + +if (len > datasz) +return -EAGAIN ; + +if (copy_to_user (datap, prop->value, len)) +return -EFAULT ; + +return 0 ; } static int devtree_get_uint(struct device_node *np, char *name,
Signature · 1 line
2.1.1
RFC PATCH v2 4/4 vfio: platform: devtree: return arrays of u32, u16, or u8 data
In reply to Antonios MotakisCertain properties of a device tree node are accessible as an array of unsigned integers, either u32, u16, or u8. Let the VFIO user query this type of device node properties. Accessing u64 arrays is not yet implemented in this RFC.
--- drivers/vfio/platform/devtree.c | 55 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 54 insertions(+), 1 deletion(-)
drivers/vfio/platform/devtree.c +54 -1
@@ -97,7 +97,60 @@ static int devtree_get_uint(struct device_node *np, char *name, uint32_t type, unsigned *lenp, void __user *datap, unsigned long datasz) { - return -EINVAL; + int ret, n; +size_t sz; +u8 *out; +int (*func)(const struct device_node *,const char *,void *,size_t ) + =NULL ; + +switch (type) { +case VFIO_DEVTREE_TYPE_U32 : + sz =sizeof (u32); + func = (int (*)(const struct device_node *, +const char *,void *,size_t )) + of_property_read_u32_array; +break ; +case VFIO_DEVTREE_TYPE_U16 : + sz =sizeof (u16); + func = (int (*)(const struct device_node *, +const char *,void *,size_t )) + of_property_read_u16_array; +break ; +case VFIO_DEVTREE_TYPE_U8 : + sz =sizeof (u8); + func = (int (*)(const struct device_node *, +const char *,void *,size_t )) + of_property_read_u8_array; +break ; + +default : +return -EINVAL ; + } + + n =of_property_count_elems_of_size (np, name, sz); +if (n <0 ) +return n; + +if (lenp) + *lenp = n * sz; + +if (n * sz > datasz) +return -EAGAIN ; + + out =kcalloc (n, sz,GFP_KERNEL ); +if (!out) +return -EFAULT ; + + ret =func (np, 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_devtree_info(struct device_node *np,
Signature · 1 line
2.1.1
A message that is not in the archive (sent off-list or not yet received): 1413474876-28544-1-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/[email protected]
Quoted 47 lines · Antonios Motakis
This RFC's intention is to show what an interface to access device node properties for the VFIO platform driver can look like.
If a device tree node corresponding to a platform device bound by VFIO PLATFORM or VFIO AMBA is available, this patch series will allow the user to query the properties associated with this device node. This can be useful for userspace drivers to automatically query parameters related to the device.
An API to return data from a device's device tree has been proposed before on these lists. The API proposed here is slightly different.
Properties to parse from the device tree are not indexed by a numerical id. The host system doesn't guarantee any specific ordering for the available properties, or that those will remain the same; while this does not happen in practice, there is nothing from the host changing the device nodes during operation. For this reason in this RFC properties are accessed by property name.
The type of the property accessed must also be known by the user. Properties types implemented in this RFC:
-VFIO_DEVTREE_TYPE_STRINGS(strings sepparated by the null character)
-VFIO_DEVTREE_TYPE_U32
-VFIO_DEVTREE_TYPE_U16
-VFIO_DEVTREE_TYPE_U8These can all be access by the ioctl
VFIO_DEVICE_GET_DEVTREE_INFO. A new ioctl was preferred instead of shoehorning the functionality inVFIO_DEVICE_GET_INFO. The structure exchanged with userspace looks like this:/**
*VFIO_DEVICE_GET_DEVTREE_INFO- _IOR(VFIO_TYPE,VFIO_BASE+ 16,
* structvfio_devtree_info)
*
* Retrieve information from the device's device tree, if available.
* Caller will initialize data[] with a single string with the requested
* devicetree property name, and type depending on whether a array of strings
* or an array of u32 values is expected. On success, data[] will be extended
* with the requested information, either as an array of u32, or with a list
* of strings sepparated by the NULL terminating character.
* Return: 0 on success, -errno on failure.
*/struct vfio_devtree_info { __u32 argsz; __u32 type;#define
VFIO_DEVTREE_PROP_LIST0
#defineVFIO_DEVTREE_TYPE_STRINGS1
#defineVFIO_DEVTREE_TYPE_U82
#defineVFIO_DEVTREE_TYPE_U163
Quoted 5 lines
#define VFIO_DEVTREE_TYPE_U32 4 __u32 length; __u8 data[]; };#define
VFIO_DEVICE_GET_DEVTREE_INFO_IO(VFIO_TYPE, VFIO_BASE + 17)
Seems pretty reasonable. We should add a flags variable to vfio_devtree_info as well. General question, in order to get a VFIO device file descriptor, the user already needs to know the name of the device. Presumably they'll get this from sysfs or otherwise just know it in advance. Is that redundant information to what we're providing here? What other information already exists in sysfs for device tree devices that we're duplicating here for the sake of creating a VFIO mechanism? If it's not already exposed in sysfs, should it be? Thanks,
Alex
Quoted 34 lines
The length of the property will be reported in length, so the user can reallocate the structure if the data does not fit the first time the call is used.
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.
TODOs:
- 64 bit values support
- We can consider to rebase this on the patch series by Rafael J. Wysocki:
"[PATCH v4 00/13] Add ACPI_DSDand unified device properties support" This would make 64 bit support more straightforward as it already includes the APIs we need for 64 bit OF values.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 codeAntonios Motakis (4):
vfio: platform: add device tree info API and skeleton
vfio: platform: devtree: return available property names
vfio: platform: devtree: access property as a list of strings
vfio: platform: devtree: return arrays of u32, u16, or u8 datadrivers/vfio/platform/Makefile | 3 +- drivers/vfio/platform/devtree.c | 199 ++++++++++++++++++++++++++ drivers/vfio/platform/vfio_platform_common.c | 39 +++++ drivers/vfio/platform/vfio_platform_private.h | 6 + include/uapi/linux/vfio.h | 26 ++++ 5 files changed, 272 insertions(+), 1 deletion(-) create mode 100644 drivers/vfio/platform/devtree.c
A message that is not in the archive (sent off-list or not yet received): 1414015019.4202.281.camel-85EaTFmN5p//[email protected]
Quoted 54 lines · Alex Williamson
Quoted 51 lines · Antonios Motakis
This RFC's intention is to show what an interface to access device node properties for the VFIO platform driver can look like.
If a device tree node corresponding to a platform device bound by VFIO PLATFORM or VFIO AMBA is available, this patch series will allow the user to query the properties associated with this device node. This can be useful for userspace drivers to automatically query parameters related to the device.
An API to return data from a device's device tree has been proposed before on these lists. The API proposed here is slightly different.
Properties to parse from the device tree are not indexed by a numerical id. The host system doesn't guarantee any specific ordering for the available properties, or that those will remain the same; while this does not happen in practice, there is nothing from the host changing the device nodes during operation. For this reason in this RFC properties are accessed by property name.
The type of the property accessed must also be known by the user. Properties types implemented in this RFC:
-VFIO_DEVTREE_TYPE_STRINGS(strings sepparated by the null character)
-VFIO_DEVTREE_TYPE_U32
-VFIO_DEVTREE_TYPE_U16
-VFIO_DEVTREE_TYPE_U8These can all be access by the ioctl
VFIO_DEVICE_GET_DEVTREE_INFO. A new ioctl was preferred instead of shoehorning the functionality inVFIO_DEVICE_GET_INFO. The structure exchanged with userspace looks like this:/**
*VFIO_DEVICE_GET_DEVTREE_INFO- _IOR(VFIO_TYPE,VFIO_BASE+ 16,
* structvfio_devtree_info)
*
* Retrieve information from the device's device tree, if available.
* Caller will initialize data[] with a single string with the requested
* devicetree property name, and type depending on whether a array of strings
* or an array of u32 values is expected. On success, data[] will be extended
* with the requested information, either as an array of u32, or with a list
* of strings sepparated by the NULL terminating character.
* Return: 0 on success, -errno on failure.
*/struct vfio_devtree_info { __u32 argsz; __u32 type; #define VFIO_DEVTREE_PROP_LIST 0 #define VFIO_DEVTREE_TYPE_STRINGS 1 #define VFIO_DEVTREE_TYPE_U8 2 #define VFIO_DEVTREE_TYPE_U16 3 #define VFIO_DEVTREE_TYPE_U32 4 __u32 length; __u8 data[]; };Quoted 1 line
#define
VFIO_DEVICE_GET_DEVTREE_INFO_IO(VFIO_TYPE, VFIO_BASE + 17)
Quoted 2 lines
Seems pretty reasonable. We should add a flags variable to
vfio_devtree_infoas well. General question, in order to get a VFIO
Hm, any idea what kind of flags we might want to add in the future? Generally what we have is key-value pairs of the above types.
Quoted 6 lines
device file descriptor, the user already needs to know the name of the device. Presumably they'll get this from sysfs or otherwise just know it in advance. Is that redundant information to what we're providing here? What other information already exists in sysfs for device tree devices that we're duplicating here for the sake of creating a VFIO mechanism? If it's not already exposed in sysfs, should it be? Thanks,
Yeah, it is kinda redundant information, but maybe it is not necessary to explicitly mask the device name just because it is also available otherwise. The full_name though is not available, which includes the path on the device tree.
The information for a device is used by a driver for that device. For example for the PL330 DMA controller, the driver finds out from the device tree the number of DMA channels available and other configuration time parameters. This is information that might not be otherwise available from the device itself, so it should be exposed to the driver.
This information is also available in /proc/device-tree, but a VFIO driver shouldn't have to go through that in my view.
Quoted 40 lines
Alex
Quoted 34 lines
The length of the property will be reported in length, so the user can reallocate the structure if the data does not fit the first time the call is used.
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.
TODOs:
- 64 bit values support
- We can consider to rebase this on the patch series by Rafael J. Wysocki:
"[PATCH v4 00/13] Add ACPI_DSDand unified device properties support" This would make 64 bit support more straightforward as it already includes the APIs we need for 64 bit OF values.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 codeAntonios Motakis (4):
vfio: platform: add device tree info API and skeleton
vfio: platform: devtree: return available property names
vfio: platform: devtree: access property as a list of strings
vfio: platform: devtree: return arrays of u32, u16, or u8 datadrivers/vfio/platform/Makefile | 3 +- drivers/vfio/platform/devtree.c | 199 ++++++++++++++++++++++++++ drivers/vfio/platform/vfio_platform_common.c | 39 +++++ drivers/vfio/platform/vfio_platform_private.h | 6 + include/uapi/linux/vfio.h | 26 ++++ 5 files changed, 272 insertions(+), 1 deletion(-) create mode 100644 drivers/vfio/platform/devtree.c