On Tue, Aug 19, 2014 at 10:27 PM, Joel Schopp <joel.schopp@xxxxxxx> wrote: > > > > This RFC's intention is to show what an interface to access device node > > properties for VFIO_PLATFORM can look like. > > > > If a device tree node corresponding to a platform device bound by VFIO_PLATFORM > > 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. So 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_ARR_TYPE_STRING (strings sepparated by the null character) > > - VFIO_DEVTREE_ARR_TYPE_U32 > > - VFIO_DEVTREE_ARR_TYPE_U16 > > - VFIO_DEVTREE_ARR_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 looks like this: > > You'll have to forgive my ignorance on the history. But with the dtc > tool already supporting a filesystem representation (--in-format=fs), > with the dtc tool source already built into qemu, and having an example > implementation of such an interface in /proc/device-tree/ why is an > ioctl interface preferred over a filesystem interface? > Hello Joel, VFIO already exposes an ioctl interface, so from the side of VFIO I think it wouldn't make sense to add another interface just for the device node data of the target device. I don't think the existing /proc interface would be appropriate to use since (1) you would have to give to the VFIO user (e.g. QEMU) access to the whole hierarchy (2) the VFIO user would have to implement logic to figure out which node it needs to get data from. One thing to keep in mind is that VFIO is not designed to be used only by QEMU. Taking as an example a hypothetical user space driver for the PL330 DMAC, I think it makes sense to be able to directly get from VFIO the right values for #dma-cells, #dma-channels, #dma-requests, etc. Of course QEMU could let the user override any values via any format QEMU supports, but IMHO out of the box it would make sense to use an interface such as the proposed one. -- Antonios Motakis Virtual Open Systems -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
