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

[Christoffer Dall <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

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?

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

-Christoffer