public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Tom Lyon <pugs@cisco.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	randy.dunlap@oracle.com, arnd@arndb.de, chrisw@sous-sol.org,
	joro@8bytes.org, hjk@linutronix.de, avi@redhat.com,
	gregkh@suse.de, aafabbri@cisco.com, scofeldm@cisco.com
Subject: Re: [PATCH V3] VFIO driver: Non-privileged user level PCI drivers
Date: Wed, 28 Jul 2010 16:13:19 -0600	[thread overview]
Message-ID: <1280355199.3919.22.camel@x201> (raw)
In-Reply-To: <20100728215739.GA9671@redhat.com>

On Thu, 2010-07-29 at 00:57 +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 28, 2010 at 03:57:02PM -0600, Alex Williamson wrote:
> > 
> > Something like GET_MSIX_VECTORS seems like a user library routine to me.
> > The PCI config space is well specified and if we try to do more than
> > shortcut trivial operations (like getting the BAR length), we risk
> > losing functionality.  And for my purposes, translating to and from a
> > made up API to PCI for the guest seems like a pain.
> 
> Won't a userspace library do just as well for you?

You mean aside from qemu's reluctance to add dependencies for more
libraries?  My only concern is that I want enough virtualized/raw config
space that I'm not always translating PCI config accesses from the guest
into some userspace API.  If it makes sense to do this for things like
MSI, since I need someone to figure out what resources can actually be
allocated on the host, then maybe the library makes sense for that.
Then again, if every user needs to do this, let the vfio kernel driver
check what it can get and virtualize the available MSIs in exposed
config space, and my driver would be even happier.

Alex


  reply	other threads:[~2010-07-28 22:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-16 21:58 [PATCH V3] VFIO driver: Non-privileged user level PCI drivers Tom Lyon
2010-07-17  8:45 ` Piotr Jaroszyński
2010-07-20 20:20   ` Greg KH
2010-07-18  9:39 ` Michael S. Tsirkin
2010-07-19  4:56   ` Alex Williamson
2010-07-19 10:06     ` Michael S. Tsirkin
2010-07-27 22:13       ` Tom Lyon
2010-07-27 23:53         ` Michael S. Tsirkin
2010-07-28 21:14           ` Tom Lyon
2010-07-28 21:46             ` Michael S. Tsirkin
2010-07-28 21:57             ` Alex Williamson
2010-07-28 21:57               ` Michael S. Tsirkin
2010-07-28 22:13                 ` Alex Williamson [this message]
2010-07-29 14:27                   ` Michael S. Tsirkin
2010-07-30 20:42                     ` Alex Williamson

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=1280355199.3919.22.camel@x201 \
    --to=alex.williamson@redhat.com \
    --cc=aafabbri@cisco.com \
    --cc=arnd@arndb.de \
    --cc=avi@redhat.com \
    --cc=chrisw@sous-sol.org \
    --cc=gregkh@suse.de \
    --cc=hjk@linutronix.de \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=pugs@cisco.com \
    --cc=randy.dunlap@oracle.com \
    --cc=scofeldm@cisco.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