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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
