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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox