public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
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: Fri, 2 Sep 2011 12:50:23 -0500	[thread overview]
Message-ID: <4E61175F.5070602@freescale.com> (raw)
In-Reply-To: <20110902155710.GA18389@redhat.com>

On 09/02/2011 10:57 AM, Michael S. Tsirkin wrote:
> On Thu, Sep 01, 2011 at 03:26:01PM -0500, Scott Wood wrote:
>> 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?
> 
> For example, for a property X, instead of adding a structure
> with identifier X, implement ioctl GET_X. Userspace
> calls this ioctl, an error implies the property
> is not present.

Why is this better?

>>> 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".
> 
> For example resources are already there in sysfs.

Their relationship to vfio regions, and their offsets in the fd, is not.

>>> 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
> 
> So you are saying the user already has sysfs path?
> I thought the point was to pass all info through
> a single fd.

No, as I understand it the point is to provide access through that fd,
as well as information that is specific to that fd.  Whether any
particular extra bit of information gets included there is a question of
convenience -- which should not be ignored in interface design.

-Scott


      reply	other threads:[~2011-09-02 17:50 UTC|newest]

Thread overview: 13+ 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 19:04 ` [Qemu-devel] " Anthony Liguori
2011-08-29 19:32   ` Scott Wood
2011-08-29 19:51 ` Alex Williamson
2011-08-29 21:58   ` Scott Wood
2011-08-29 22:46     ` Alex Williamson
2011-08-29 23:14       ` Scott Wood
2011-08-30  4:55         ` Alex Williamson
2011-08-30 16:54           ` Scott Wood
2011-09-01 20:00 ` Michael S. Tsirkin
2011-09-01 20:26   ` Scott Wood
2011-09-02 15:57     ` Michael S. Tsirkin
2011-09-02 17:50       ` Scott Wood [this message]

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=4E61175F.5070602@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox