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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 02, 2015 at 01:28:19PM -0600, Alex Williamson wrote:
> On Wed, 2015-09-30 at 11:07 +0200, Baptiste Reynal wrote:
> > This RFC's intention is to show what an interface to access device
> > properties for the VFIO platform driver can look like. These properties
> > can be retrieved from the device tree node describing the device, or ACPI
> > properties.
> > 
> > If a device property corresponding to a platform device bound to VFIO PLATFORM
> > or VFIO AMBA is available, this patch series will allow the user to query
> > for this information. This can be useful for userspace drivers to automatically
> > query parameters related to the device.
> > 
> > Specifically for QEMU, reading the "compatible" property of the device tree
> > node could be of use to find out what device is being assigned to the guest and
> > handle appropriately a wider range of devices in the future, and to generate an
> > appropriate device tree for the guest.
> > 
> > Older versions of this series were specifically targeted at device tree
> > properties. The v3 has been reworked on top of Rafael J. Wysocki's
> > uniform device properties API for device tree and ACPI devices. This will allow
> > us to use the API in the future with devices described via ACPI.
> > 
> > The API to get the list of available properties and the device tree full_name
> > have been removed. These probably don't serve an useful purpose, as the user
> > of this API need to know anyway what properties are specific to the device he
> > wants to access with VFIO. If we decide to reintroduce the list of properties
> > in the future, the generic device properties API in the kernel will have to
> > be extended accordingly.
> 
> If we wanted to describe device properties via vfio, perhaps this is a
> reasonable approach.  However, why would we want to do that?  How are
> these device properties unique to vfio?  Are there other users that
> might want to learn these properties?  How will they get them?  Perhaps
> they would decide to expose them via sysfs for everyone, making this
> interface redundant.  Why not start with exposing device properties to
> userspace in a way that's not specific to vfio?  Thanks,
> 
We discussed this for the purposes of ARM during SFO15 last week, and
basically arrived at the conclusion that the resonable thing to do is to
rely on sysfs device tree parsing in userspace.  We don't have a great
solution for ACPI yet, but we also don't know of any ACPI-only devices
that want platform device passthrough yet.

-Christoffer
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm



[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux