Re: Building assigned device guest dt node from host device tree ...

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

Hi Alex,
On 09/01/2015 07:00 PM, Alexander Graf wrote:
> 
> 
>> Am 01.09.2015 um 17:29 schrieb Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>>
>> 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.
> 
> Best path imho is to have the vfio fd expose its path via an ioctl. Didn't we have that?
no we don't. We may extend VFIO_DEVICE_GET_INFO ioctl though?
> 
>>
>> - I currently prototype this functionality using popen + find. That
>> works but relies on "find" executable availability. Is it a valid
>> assumption?
> 
> No :)
You can't win if you don't play ;-)
> 
>>
>> - 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.
OK. I will do that shortly.

Many thanks for your reply

Eric
> 
> Alex
> 
>>
>> 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
>>
>>
>>
>>> On 09/01/2015 11:28 AM, Christoffer Dall wrote:
>>> 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
>>