linux-kernel.vger.kernel.org archive mirror
 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>,
	randy.dunlap@oracle.com, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, 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 V2] VFIO driver: Non-privileged user level PCI drivers
Date: Wed, 30 Jun 2010 08:00:26 -0600	[thread overview]
Message-ID: <1277906426.3164.40.camel@x201> (raw)
In-Reply-To: <20100630133639.GB4226@redhat.com>

On Wed, 2010-06-30 at 16:36 +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 30, 2010 at 12:14:12AM -0600, Alex Williamson wrote:
> > On Tue, 2010-06-08 at 14:21 -0700, Tom Lyon wrote:
> > > The VFIO "driver" is used to allow privileged AND non-privileged processes to 
> > > implement user-level device drivers for any well-behaved PCI, PCI-X, and PCIe
> > > devices.
> > 
> > Hi Tom,
> > 
> > I found a few bugs.  Patch below.  The first chunk clears the
> > pci_config_map on close, otherwise we end up passing virtualized state
> > from one user to the next.  The second is an off by one in the basic
> > perms.  Finally, vfio_bar_fixup() needs an overhaul.  It wasn't setting
> > the lower bits right and is allowing virtual writes of bits that aren't
> > aligned to the size.  This section probably needs another pass or two of
> > refinement.  Thanks,
> > 
> > Alex
> > 
> 
> I still don't see why are we sticking all this emulation in kernel.  It
> is far from performance hotpath and can easily be emulated in userspace.
> qemu does this, you can lift code from there if you like.
> Maybe we need to protect the BARs from being manipulated by userspace,
> but that should be all. No need for tables.

The benefit I see so far is that it removes duplicate code.  Should
every user of this interface try to extract qemu's PCI config space
emulation and jury rig it into their code base?  Tom is already
providing access to more capability bits than the kvm device assignment
code.  If the kernel community will accept it, I think it saves vfio
usperspace writers some hassle and provides a better environment by
having emulation in a single, well tested, hopefully well used place.
Thanks,

Alex


  reply	other threads:[~2010-06-30 14:01 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-08 21:21 [PATCH V2] VFIO driver: Non-privileged user level PCI drivers Tom Lyon
2010-06-08 21:41 ` Randy Dunlap
2010-06-09 12:11   ` Arnd Bergmann
2010-06-08 21:45 ` Randy Dunlap
2010-06-08 22:38 ` Michael S. Tsirkin
2010-06-08 23:54   ` Tom Lyon
2010-06-09  5:45     ` Michael S. Tsirkin
2010-06-11 22:15       ` Tom Lyon
2010-06-13 10:23         ` Michael S. Tsirkin
2010-06-17 21:14           ` Tom Lyon
2010-06-17 21:47             ` Michael S. Tsirkin
2010-06-24 12:22             ` Joerg Roedel
2010-06-24 15:03               ` Michael S. Tsirkin
2010-06-09 11:04 ` Avi Kivity
2010-06-09 15:25   ` Greg KH
2010-06-09 16:05 ` Michael S. Tsirkin
2010-06-10 17:27 ` Konrad Rzeszutek Wilk
2010-06-11  1:58   ` Tom Lyon
2010-06-11  4:19     ` Greg KH
2010-06-11  4:56     ` Avi Kivity
2010-06-30  6:14 ` Alex Williamson
2010-06-30 13:36   ` Michael S. Tsirkin
2010-06-30 14:00     ` Alex Williamson [this message]
2010-06-30 22:17   ` Tom Lyon
2010-06-30 22:32     ` Michael S. Tsirkin
2010-06-30 22:49       ` Tom Lyon
2010-07-01  4:16 ` Alex Williamson
2010-07-01  4:30   ` Tom Lyon
2010-07-01  5:16     ` Alex Williamson
2010-07-01 15:29 ` Alex Williamson
2010-07-01 15:31   ` Michael S. Tsirkin
2010-07-01 15:48     ` Alex Williamson
2010-07-01 16:22       ` Michael S. Tsirkin
2010-07-01 18:49       ` Tom Lyon
2010-07-06  4:50 ` 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=1277906426.3164.40.camel@x201 \
    --to=alex.williamson@redhat.com \
    --cc=aafabbri@cisco.com \
    --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;
as well as URLs for NNTP newsgroup(s).