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

[Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

Hi Christoffer,
On 08/30/2015 04:06 PM, Christoffer Dall wrote:
> Hi Eric,
> 
> On Thu, Aug 27, 2015 at 07:16:00PM +0200, Eric Auger wrote:
>> Hi Alex,
>> On 08/27/2015 06:11 PM, Alex Williamson wrote:
>>> On Thu, 2015-08-27 at 14:52 +0200, Eric Auger wrote:
>>>> 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,
>>
>> 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.
>>
> 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? ...

Please let me know if I answered to your question.

Best Regards

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