Re: [RFC PATCH v3 0/3] vfio: platform: return device properties for a platform device

[Christoffer Dall <christoffer.dall@linaro.org>]

Hi Eric,

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

[...]

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

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.

> 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