From: Scott Wood <scottwood@freescale.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Yoder Stuart-B08248 <B08248@freescale.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Wood Scott-B07421 <B07421@freescale.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Joerg.Roedel@amd.com" <Joerg.Roedel@amd.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Alexander Graf <agraf@suse.de>, "avi@redhat.com" <avi@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: RFC: vfio / device assignment -- layout of device fd files
Date: Thu, 1 Sep 2011 15:26:01 -0500 [thread overview]
Message-ID: <4E5FEA59.7070201@freescale.com> (raw)
In-Reply-To: <20110901200037.GP10989@redhat.com>
On 09/01/2011 03:00 PM, Michael S. Tsirkin wrote:
> That's a very rich interface, and easy to get wrong.
> AFAIK the only reason vfio uses read/write for PCI was to avoid inventing
> a custom interface. But if you do, it looks like a set of ioctls would
> be much easier? You can even fit the existing uio infrastructure if you like.
How would it be easier than producing/parsing a static data structure?
What would it look like?
> Here's another idea: all the information is likely already available
> in sysfs.
The only major thing that is likely available elsewhere is PCI config
space, and that was not new to this proposal.
Most other material is specifically related to the vfio/dtio interface
(e.g. offsets into the file handle, arguments to the "get irq fd" ioctl,
mapping of dtio regions/interrupts to device tree nodes), and could not
be "useful to more than just vfio".
> A way to query where the device is in sysfs
> would give you *a ton* of information, including the type etc,
For PCI, the user has domain/bus/dev/fn which should be sufficient to
find that, if desired. For device-tree devices, there's a device tree
path provided for each region/interrupt.
-Scott
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Joerg.Roedel@amd.com" <Joerg.Roedel@amd.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Alexander Graf <agraf@suse.de>,
Yoder Stuart-B08248 <B08248@freescale.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"avi@redhat.com" <avi@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] RFC: vfio / device assignment -- layout of device fd files
Date: Thu, 1 Sep 2011 15:26:01 -0500 [thread overview]
Message-ID: <4E5FEA59.7070201@freescale.com> (raw)
In-Reply-To: <20110901200037.GP10989@redhat.com>
On 09/01/2011 03:00 PM, Michael S. Tsirkin wrote:
> That's a very rich interface, and easy to get wrong.
> AFAIK the only reason vfio uses read/write for PCI was to avoid inventing
> a custom interface. But if you do, it looks like a set of ioctls would
> be much easier? You can even fit the existing uio infrastructure if you like.
How would it be easier than producing/parsing a static data structure?
What would it look like?
> Here's another idea: all the information is likely already available
> in sysfs.
The only major thing that is likely available elsewhere is PCI config
space, and that was not new to this proposal.
Most other material is specifically related to the vfio/dtio interface
(e.g. offsets into the file handle, arguments to the "get irq fd" ioctl,
mapping of dtio regions/interrupts to device tree nodes), and could not
be "useful to more than just vfio".
> A way to query where the device is in sysfs
> would give you *a ton* of information, including the type etc,
For PCI, the user has domain/bus/dev/fn which should be sufficient to
find that, if desired. For device-tree devices, there's a device tree
path provided for each region/interrupt.
-Scott
next prev parent reply other threads:[~2011-09-01 20:26 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-29 16:51 RFC: vfio / device assignment -- layout of device fd files Yoder Stuart-B08248
2011-08-29 16:51 ` [Qemu-devel] " Yoder Stuart-B08248
2011-08-29 19:04 ` Anthony Liguori
2011-08-29 19:04 ` Anthony Liguori
2011-08-29 19:32 ` Scott Wood
2011-08-29 19:32 ` Scott Wood
2011-08-29 19:51 ` Alex Williamson
2011-08-29 19:51 ` [Qemu-devel] " Alex Williamson
2011-08-29 21:58 ` Scott Wood
2011-08-29 21:58 ` [Qemu-devel] " Scott Wood
2011-08-29 22:46 ` Alex Williamson
2011-08-29 22:46 ` [Qemu-devel] " Alex Williamson
2011-08-29 23:14 ` Scott Wood
2011-08-29 23:14 ` [Qemu-devel] " Scott Wood
2011-08-30 4:55 ` Alex Williamson
2011-08-30 4:55 ` [Qemu-devel] " Alex Williamson
2011-08-30 16:54 ` Scott Wood
2011-08-30 16:54 ` [Qemu-devel] " Scott Wood
2011-09-01 20:00 ` Michael S. Tsirkin
2011-09-01 20:00 ` [Qemu-devel] " Michael S. Tsirkin
2011-09-01 20:26 ` Scott Wood [this message]
2011-09-01 20:26 ` Scott Wood
2011-09-02 15:57 ` Michael S. Tsirkin
2011-09-02 15:57 ` [Qemu-devel] " Michael S. Tsirkin
2011-09-02 17:50 ` Scott Wood
2011-09-02 17:50 ` [Qemu-devel] " Scott Wood
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=4E5FEA59.7070201@freescale.com \
--to=scottwood@freescale.com \
--cc=B07421@freescale.com \
--cc=B08248@freescale.com \
--cc=Joerg.Roedel@amd.com \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.com \
--cc=avi@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=david@gibson.dropbear.id.au \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.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.