From: Christoffer Dall <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org,
kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org,
eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Subject: Re: [RFC PATCH v5 0/3] vfio: platform: return device properties for a platform device
Date: Fri, 2 Oct 2015 22:28:44 +0200 [thread overview]
Message-ID: <20151002202844.GD32011@cbox> (raw)
In-Reply-To: <1443814099.26107.124.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
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
next prev parent reply other threads:[~2015-10-02 20:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 9:07 [RFC PATCH v5 0/3] vfio: platform: return device properties for a platform device Baptiste Reynal
[not found] ` <1443604077-3155-1-git-send-email-b.reynal-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2015-10-02 19:28 ` Alex Williamson
[not found] ` <1443814099.26107.124.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-10-02 20:28 ` Christoffer Dall [this message]
2015-10-02 22:53 ` Peter Maydell
2015-10-05 9:37 ` Christoffer Dall
2015-10-05 10:07 ` Peter Maydell
[not found] ` <CAFEAcA_ZGaS__7LPFR_JJEs0=KpDNjYQB_ib2pNDLLp2S0zSMA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-05 10:32 ` Christoffer Dall
2015-10-05 10:48 ` Mark Rutland
[not found] ` <CAFEAcA84seKfSh94XFJZxBeBzRd=twj2QaFvjMeDKYhrWQu7Nw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-05 9:42 ` Baptiste Reynal
2015-10-05 9:53 ` Christoffer Dall
2015-10-05 10:04 ` Baptiste Reynal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151002202844.GD32011@cbox \
--to=christoffer.dall-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
--cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org \
--cc=tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.