From: Eric Auger <eric.auger@linaro.org>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: iommu@lists.linux-foundation.org, tech@virtualopensystems.com,
kvmarm@lists.cs.columbia.edu
Subject: Re: [RFC PATCH v3 0/3] vfio: platform: return device properties for a platform device
Date: Thu, 27 Aug 2015 19:16:00 +0200 [thread overview]
Message-ID: <55DF45D0.5040704@linaro.org> (raw)
In-Reply-To: <1440691887.20355.27.camel@redhat.com>
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.
Do you advise to read the fs directly instead of using such API?
Thanks
Eric
>
> Alex
>
>> On 12/19/2014 10:20 PM, Antonios Motakis 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 from the device tree node describing the device, or ACPI properties
>>> in the future.
>>>
>>> If a device property corresponding to a platform device bound by 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 where specifically targeted at device tree
>>> properties. This version 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.
>>>
>>> This also means a kernel including the uniform device properties API is needed
>>> to apply these patches, in additon to the VFIO patches, e.g. branch pm+acpi-3.19-rc1
>>> from https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/
>>>
>>> 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.
>>>
>>> A kernel with this series and all the dependencies applied can be pulled from
>>> branch vfio-device-properties-v3 from the repository:
>>> https://github.com/virtualopensystems/linux-kvm-arm.git
>>>
>>> Changes since v2:
>>> - Reworked on top of Rafael J. Wysocki's uniform device properties API for
>>> device tree and ACPI
>>> - Support for u64 array properties
>>> - Removed API to get list of available properties and device tree full_name
>>> Changes since v1:
>>> - Updated for VFIO platform patch series v8:
>>> VFIO AMBA devices now supported in addition to VFIO PLATFORM devices
>>> - Refactored and cleaned up the code
>>>
>>> Antonios Motakis (3):
>>> vfio: platform: add device properties skeleton and user API
>>> vfio: platform: access device property as a list of strings
>>> vfio: platform: return device properties as arrays of unsigned
>>> integers
>>>
>>> drivers/vfio/platform/Makefile | 3 +-
>>> drivers/vfio/platform/properties.c | 162 ++++++++++++++++++++++++++
>>> drivers/vfio/platform/vfio_platform_common.c | 35 ++++++
>>> drivers/vfio/platform/vfio_platform_private.h | 7 ++
>>> include/uapi/linux/vfio.h | 26 +++++
>>> 5 files changed, 232 insertions(+), 1 deletion(-)
>>> create mode 100644 drivers/vfio/platform/properties.c
>>>
>>
>
>
>
next prev parent reply other threads:[~2015-08-27 17:16 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-19 21:20 [RFC PATCH v3 0/3] vfio: platform: return device properties for a platform device Antonios Motakis
[not found] ` <1419024032-1269-1-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2014-12-19 21:20 ` [RFC PATCH v3 1/3] vfio: platform: add device properties skeleton and user API Antonios Motakis
[not found] ` <1419024032-1269-2-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2015-09-03 16:48 ` Eric Auger
2014-12-19 21:20 ` [RFC PATCH v3 2/3] vfio: platform: access device property as a list of strings Antonios Motakis
2015-09-03 16:49 ` Eric Auger
2014-12-19 21:20 ` [RFC PATCH v3 3/3] vfio: platform: return device properties as arrays of unsigned integers Antonios Motakis
[not found] ` <1419024032-1269-4-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2015-09-03 16:49 ` Eric Auger
2015-08-27 12:52 ` [RFC PATCH v3 0/3] vfio: platform: return device properties for a platform device Eric Auger
2015-08-27 13:36 ` Antonios Motakis
[not found] ` <55DF124F.8020801-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2015-08-27 13:49 ` Eric Auger
[not found] ` <55DF07F0.3070405-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-08-27 14:27 ` Christian Pinto
[not found] ` <55DF1E4B.6040604-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2015-08-27 14:55 ` Eric Auger
2015-08-27 16:11 ` Alex Williamson
2015-08-27 17:16 ` Eric Auger [this message]
[not found] ` <55DF45D0.5040704-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-08-30 14:06 ` Christoffer Dall
2015-08-31 17:02 ` Eric Auger
[not found] ` <55E48897.4090907-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-08-31 17:33 ` Christoffer Dall
2015-09-01 7:31 ` Eric Auger
2015-09-01 9:28 ` Christoffer Dall
2015-09-01 15:29 ` Building assigned device guest dt node from host device tree Eric Auger
2015-09-01 15:49 ` Peter Maydell
2015-09-01 17:00 ` Alexander Graf
[not found] ` <83D37F6C-FFE9-4C3C-AA1C-F12603954C2A-l3A5Bk7waGM@public.gmane.org>
2015-09-01 17:16 ` Eric Auger
2015-09-01 15:32 ` [RFC PATCH v3 0/3] vfio: platform: return device properties for a platform device Baptiste Reynal
[not found] ` <CAN9JPjGfuv_YOBEdZA_AD13oHej7wMCR50=zQTZmgzHx-jBj_A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-01 15:52 ` Christoffer Dall
2015-09-02 7:21 ` Baptiste Reynal
[not found] ` <CAN9JPjFwsiYzR6RtDA-5UZYoNALGu8crXVyA+m6ptsWv=qJi5A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-02 9:21 ` Christoffer Dall
2015-09-02 9:49 ` Baptiste Reynal
2015-09-02 10:32 ` Christoffer Dall
2015-09-02 13:42 ` Baptiste Reynal
2015-09-02 16:52 ` Alex Williamson
[not found] ` <1441212724.20355.306.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-03 7:42 ` Baptiste Reynal
[not found] ` <CAN9JPjF0Lex2wD=_iiriTaYdukva+rxhdwPTQnGqC5kQFCEYGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-03 8:49 ` Christoffer Dall
2015-09-03 14:18 ` Alex Williamson
2015-09-03 16:46 ` Eric Auger
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=55DF45D0.5040704@linaro.org \
--to=eric.auger@linaro.org \
--cc=alex.williamson@redhat.com \
--cc=iommu@lists.linux-foundation.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=tech@virtualopensystems.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox