All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Andreas Hartmann <andihartmann@01019freenet.de>
Cc: Dominic Eschweiler <eschweiler@fias.uni-frankfurt.de>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Hans J. Koch" <hjk@hansjkoch.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] uio_pci_generic does not export memory resources
Date: Fri, 08 Jun 2012 10:41:46 -0600	[thread overview]
Message-ID: <1339173706.26976.91.camel@ul30vt> (raw)
In-Reply-To: <4FD22552.6090609@01019freenet.de>

On Fri, 2012-06-08 at 18:16 +0200, Andreas Hartmann wrote:
> Hi Dominic,
> 
> Dominic Eschweiler wrote:
> > Am Freitag, den 08.06.2012, 08:16 -0600 schrieb Alex Williamson:
> >> Yes, thanks Jan.  This is exactly what VFIO does.  VFIO provides
> >> secure config space access, resource access, DMA mapping services, and
> >> full interrupt support to userspace.  
> > 
> > I know about VFIO, but we need some support for that stuff relatively
> > soon. That's the reason why I'm currently working on it to make UIO DMA
> > capable. My extensions probably do not play well with IOMMUs and they
> > therefore won't make it to mainline anyhow (i learned that today ;-).
> 
> I'm not sure if vfio covers your needs completely, but I tested it here
> very successfully. I was able to create a patch, which can be applied to
> opensuse 3.4.1 kernel and which seams to run well.
> 
> I even managed to integrate it into libvirt :-). So it is usable as
> every other traditional VM, too.

Oh, please post the patch for libvirt!

> Besides the problem with AMD IOMMU, which requires to unbind a whole
> group of devices in some cases (PCI passthrough - not PCIe), it's really
> cool! And it's usable now!

If you're feeling adventurous (and know that this may not make it
upstream), you can do something like this:

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index ab0dba0..5c26804 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3161,11 +3161,22 @@ struct pci_dev *pci_get_dma_source(struct pci_dev *dev)
        return pci_dev_get(dev);
 }
 
+static int pci_func_supports_acs(struct pci_dev *dev, u16 acs_flags)
+{
+       return 1;
+}
+
 static const struct pci_dev_acs_enabled {
        u16 vendor;
        u16 device;
        int (*acs_enabled)(struct pci_dev *dev, u16 acs_flags);
 } pci_dev_acs_enabled[] = {
+       { 0x1002, 0x4385, pci_func_supports_acs },
+       { 0x1002, 0x439c, pci_func_supports_acs },
+       { 0x1002, 0x4383, pci_func_supports_acs },
+       { 0x1002, 0x439d, pci_func_supports_acs },
+       { 0x1002, 0x4384, pci_func_supports_acs },
+       { 0x1002, 0x4399, pci_func_supports_acs },
        { 0 }
 };

Hmm, I wonder if we should make a kernel boot parameter that allows
whitelisting some devices.  I think it would have to taint the kernel
but there's probably sufficient interest for usability vs
supportability.  Thanks,

Alex

  reply	other threads:[~2012-06-08 16:41 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08 11:56 [PATCH] uio_pci_generic does not export memory resources Dominic Eschweiler
2012-06-08 13:03 ` Michael S. Tsirkin
2012-06-08 13:16   ` Jan Kiszka
2012-06-08 14:16     ` Alex Williamson
2012-06-08 14:47       ` Dominic Eschweiler
2012-06-08 15:06         ` Alex Williamson
2012-06-08 16:16         ` Andreas Hartmann
2012-06-08 16:41           ` Alex Williamson [this message]
2012-06-09  9:28             ` Andreas Hartmann
2012-06-09 14:50               ` Alex Williamson
2012-06-09 16:25                 ` Andreas Hartmann
2012-06-09 16:55                   ` Alex Williamson
2012-06-10  7:21                     ` Andreas Hartmann
2012-06-10 19:12                       ` Andreas Hartmann
2012-06-10 14:12                 ` Michael S. Tsirkin
2012-06-08 16:44           ` Hans J. Koch
2012-06-08 16:59             ` Jan Kiszka
2012-06-08 17:11             ` Alex Williamson
2012-06-10 14:18               ` Michael S. Tsirkin
2012-06-10 16:09                 ` Alex Williamson
2012-06-10 16:44                   ` Michael S. Tsirkin
2012-06-10 17:38                     ` Alex Williamson
2012-06-10 18:43                       ` Michael S. Tsirkin
2012-06-10 19:00                       ` Michael S. Tsirkin
2012-06-10 19:11                         ` Hans J. Koch
2012-06-10 19:16                           ` Michael S. Tsirkin
2012-06-10 20:19                             ` Hans J. Koch
2012-06-10 19:01               ` Hans J. Koch
2012-06-08 14:28   ` Dominic Eschweiler
2012-06-08 15:18     ` Hans J. Koch
2012-06-08 15:45       ` Dominic Eschweiler
2012-06-08 15:57         ` Hans J. Koch
2012-06-08 16:23           ` Dominic Eschweiler
2012-06-08 16:37             ` Hans J. Koch
2012-06-08 17:07               ` Dominic Eschweiler
2012-06-08 17:11                 ` Hans J. Koch
2012-06-08 16:39             ` Michael S. Tsirkin
2012-06-08 16:07 ` Hans J. Koch

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=1339173706.26976.91.camel@ul30vt \
    --to=alex.williamson@redhat.com \
    --cc=andihartmann@01019freenet.de \
    --cc=eschweiler@fias.uni-frankfurt.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=hjk@hansjkoch.de \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.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 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.