[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1280355199.3919.22.camel@x201>
Date: Wed, 28 Jul 2010 16:13:19 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Tom Lyon <pugs@...co.com>, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, randy.dunlap@...cle.com, arnd@...db.de,
chrisw@...s-sol.org, joro@...tes.org, hjk@...utronix.de,
avi@...hat.com, gregkh@...e.de, aafabbri@...co.com,
scofeldm@...co.com
Subject: Re: [PATCH V3] VFIO driver: Non-privileged user level PCI drivers
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists