On Tue, 2013-02-12 at 10:45 +1100, Alexey Kardashevskiy wrote:
On 12/02/13 09:17, Alex Williamson wrote:
On Mon, 2013-02-11 at 22:54 +1100, Alexey Kardashevskiy wrote:
VFIO implements platform independent stuff such as
a PCI driver, BAR access (via read/write on a file descriptor
On Wed, 2012-12-12 at 17:14 +1100, Alexey Kardashevskiy wrote:
On 08/12/12 04:38, Alex Williamson wrote:
+static int __init tce_iommu_init(void)
+{
+ struct pci_dev *pdev = NULL;
+ struct iommu_table *tbl;
+ struct iommu_group *grp;
+
+ /* Allocate and initialize IOMMU groups
On Wed, 2012-12-12 at 17:59 +1100, Alexey Kardashevskiy wrote:
On 08/12/12 04:01, Alex Williamson wrote:
+ case VFIO_IOMMU_MAP_DMA: {
+ vfio_iommu_spapr_tce_dma_map param;
+ struct iommu_table *tbl = container-tbl;
+ enum dma_data_direction direction
On Wed, 2012-12-12 at 23:34 +1100, Alexey Kardashevskiy wrote:
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).
It also
On Thu, 2012-12-13 at 13:57 +1100, Benjamin Herrenschmidt wrote:
On Wed, 2012-12-12 at 16:30 -0700, Alex Williamson wrote:
Locked page accounting in this version is very, very broken. How do
powerpc folks feel about seemingly generic kernel iommu interfaces
messing with the current task mm
.
+ * Author: Alex Williamson alex.william...@redhat.com
+ */
+
+#include linux/module.h
+#include linux/pci.h
+#include linux/slab.h
+#include linux/uaccess.h
+#include linux/err.h
+#include linux/vfio.h
+#include asm/iommu.h
+
+#define DRIVER_VERSION 0.1
+#define DRIVER_AUTHOR
On Fri, 2012-12-07 at 18:35 +1100, Alexey Kardashevskiy wrote:
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).
It also
On Tue, 2012-12-04 at 19:12 +1100, Alexey Kardashevskiy wrote:
On 04/12/12 04:35, Alex Williamson wrote:
On Mon, 2012-12-03 at 13:52 +1100, Alexey Kardashevskiy wrote:
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non
On Mon, 2012-12-03 at 13:52 +1100, Alexey Kardashevskiy wrote:
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).
It also
.
+ * Author: Alex Williamson alex.william...@redhat.com
+ */
+
+#include linux/module.h
+#include linux/pci.h
+#include linux/slab.h
+#include linux/uaccess.h
+#include linux/err.h
+#include linux/vfio.h
+#include asm/iommu.h
+
+#define DRIVER_VERSION 0.1
+#define DRIVER_AUTHOR
On Fri, 2012-11-30 at 17:14 +1100, Alexey Kardashevskiy wrote:
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).
It also
.
+ * Author: Alex Williamson alex.william...@redhat.com
+ */
+
+#include linux/module.h
+#include linux/pci.h
+#include linux/slab.h
+#include linux/uaccess.h
+#include linux/err.h
+#include linux/vfio.h
+#include asm/iommu.h
+
+#define DRIVER_VERSION 0.1
+#define DRIVER_AUTHOR
On Wed, 2012-11-28 at 18:18 +1100, Alexey Kardashevskiy wrote:
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).
It also
On Thu, 2012-11-29 at 14:53 +1100, Alexey Kardashevskiy wrote:
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).
It also
On Thu, 2012-11-22 at 11:56 +, Sethi Varun-B16395 wrote:
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Alex Williamson
Sent: Tuesday, November 20, 2012 11:50 PM
To: Alexey Kardashevskiy
Cc: Benjamin
On Fri, 2012-11-23 at 13:02 +1100, Alexey Kardashevskiy wrote:
On 22/11/12 22:56, Sethi Varun-B16395 wrote:
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Alex Williamson
Sent: Tuesday, November 20, 2012 11
On Mon, 2012-11-26 at 08:18 -0700, Alex Williamson wrote:
On Fri, 2012-11-23 at 13:02 +1100, Alexey Kardashevskiy wrote:
On 22/11/12 22:56, Sethi Varun-B16395 wrote:
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org
.
+ * Author: Alex Williamson alex.william...@redhat.com
+ */
+
+#include linux/module.h
+#include linux/pci.h
+#include linux/slab.h
+#include linux/uaccess.h
+#include linux/err.h
+#include linux/vfio.h
+#include asm/iommu.h
+
+#define DRIVER_VERSION 0.1
+#define DRIVER_AUTHOR
On Tue, 2012-11-27 at 14:28 +1100, Alexey Kardashevskiy wrote:
On 27/11/12 05:04, Alex Williamson wrote:
On Mon, 2012-11-26 at 08:18 -0700, Alex Williamson wrote:
On Fri, 2012-11-23 at 13:02 +1100, Alexey Kardashevskiy wrote:
On 22/11/12 22:56, Sethi Varun-B16395 wrote:
-Original
On Tue, 2012-11-27 at 15:06 +1100, Alexey Kardashevskiy wrote:
On 27/11/12 05:20, Alex Williamson wrote:
On Fri, 2012-11-23 at 20:03 +1100, Alexey Kardashevskiy wrote:
VFIO implements platform independent stuff such as
a PCI driver, BAR access (via read/write on a file descriptor
On Fri, 2012-11-23 at 20:03 +1100, Alexey Kardashevskiy wrote:
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).
It also
On Tue, 2012-11-27 at 15:58 +1100, Alexey Kardashevskiy wrote:
On 27/11/12 15:29, Alex Williamson wrote:
On Tue, 2012-11-27 at 15:06 +1100, Alexey Kardashevskiy wrote:
On 27/11/12 05:20, Alex Williamson wrote:
On Fri, 2012-11-23 at 20:03 +1100, Alexey Kardashevskiy wrote:
VFIO implements
as
+ * published by the Free Software Foundation.
+ *
+ * Derived from original vfio_iommu_type1.c:
+ * Copyright (C) 2012 Red Hat, Inc. All rights reserved.
+ * Author: Alex Williamson alex.william...@redhat.com
+ */
+
+#include linux/module.h
+#include linux/pci.h
+#include linux
On Thu, 2012-10-11 at 19:19 +1100, Alexey Kardashevskiy wrote:
Ok I'm back, nothing seems happened during last month :)
Nope, not much ;) Note that I added a hack to avoid the INTx EOI
problem, I expect it should work for you too.
On 14/09/12 14:35, Alex Williamson wrote:
On Fri, 2012-09-14
On Tue, 2012-09-11 at 18:28 +1000, Alexey Kardashevskiy wrote:
On 11/09/12 02:02, Alex Williamson wrote:
On Tue, 2012-09-04 at 17:33 +1000, Alexey Kardashevskiy wrote:
Cc: David Gibson da...@gibson.dropbear.id.au
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau
On Thu, 2012-09-13 at 17:41 -0500, Scott Wood wrote:
On Thu, Sep 13, 2012 at 04:34:59PM -0600, Alex Williamson wrote:
Do you only want VFIO drivers to work on POWER if they're written by
POWER people? Ideally there are a few simple concepts: a) devices have
an I/O virtual address space
On Fri, 2012-09-14 at 10:51 +1000, Alexey Kardashevskiy wrote:
On 14/09/12 08:34, Alex Williamson wrote:
On Tue, 2012-09-11 at 18:28 +1000, Alexey Kardashevskiy wrote:
On 11/09/12 02:02, Alex Williamson wrote:
On Tue, 2012-09-04 at 17:33 +1000, Alexey Kardashevskiy wrote:
Cc: David Gibson
Software Foundation.
+ *
+ * Derived from original vfio_iommu_x86.c:
Should this be _type1? Only the mail archives are going to remember
there was a _x86, so the renamed version is probably a better reference.
+ * Copyright (C) 2012 Red Hat, Inc. All rights reserved.
+ * Author: Alex
On Wed, 2012-09-05 at 15:27 +1000, Alexey Kardashevskiy wrote:
On 05/09/12 15:17, Benjamin Herrenschmidt wrote:
On Tue, 2012-09-04 at 22:57 -0600, Alex Williamson wrote:
Do we need an extra region info field, or is it sufficient that we
define a region to be mmap'able with getpagesize
On Wed, 2012-09-05 at 11:16 +1000, Benjamin Herrenschmidt wrote:
It's still bad in more ways that I care to explain...
Well it is right before pci_reassigndev_resource_alignment() which is
common and does the same thing.
The main one is that you do the fixup in a very wrong place
On Thu, 2011-09-01 at 14:10 +1000, David Gibson wrote:
On Tue, Aug 30, 2011 at 08:51:38AM -0600, Alex Williamson wrote:
On Tue, 2011-08-30 at 17:48 +1000, David Gibson wrote:
On Mon, Aug 29, 2011 at 10:24:43PM -0600, Alex Williamson wrote:
On Tue, 2011-08-30 at 13:04 +1000, David Gibson
On Tue, 2011-08-30 at 17:48 +1000, David Gibson wrote:
On Mon, Aug 29, 2011 at 10:24:43PM -0600, Alex Williamson wrote:
On Tue, 2011-08-30 at 13:04 +1000, David Gibson wrote:
On Fri, Aug 26, 2011 at 11:05:23AM -0600, Alex Williamson wrote:
I don't think too much has changed since
On Tue, 2011-08-30 at 13:04 +1000, David Gibson wrote:
On Fri, Aug 26, 2011 at 11:05:23AM -0600, Alex Williamson wrote:
I don't think too much has changed since the previous email went out,
but it seems like a good idea to post a summary in case there were
suggestions or objections
I don't think too much has changed since the previous email went out,
but it seems like a good idea to post a summary in case there were
suggestions or objections that I missed.
VFIO v2 will rely on the platform iommu driver reporting grouping
information. Again, a group is a set of devices for
On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
Hi Alex,
On Wed, Aug 24, 2011 at 05:13:49PM -0400, Alex Williamson wrote:
Is this roughly what you're thinking of for the iommu_group component?
Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
support
On Wed, 2011-08-24 at 09:51 +1000, Benjamin Herrenschmidt wrote:
For us the most simple and logical approach (which is also what pHyp
uses and what Linux handles well) is really to expose a given PCI host
bridge per group to the guest. Believe it or not, it makes things
easier :-)
On Wed, 2011-08-24 at 10:43 +0200, Joerg Roedel wrote:
On Tue, Aug 23, 2011 at 03:30:06PM -0400, Alex Williamson wrote:
On Tue, 2011-08-23 at 07:01 +1000, Benjamin Herrenschmidt wrote:
Could be tho in what form ? returning sysfs pathes ?
I'm at a loss there, please suggest. I think
On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote:
On Tue, Aug 23, 2011 at 01:08:29PM -0400, Alex Williamson wrote:
On Tue, 2011-08-23 at 15:14 +0200, Roedel, Joerg wrote:
Handling it through fds is a good idea. This makes sure that everything
belongs to one process. I am
Joerg,
Is this roughly what you're thinking of for the iommu_group component?
Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
support in the iommu base. Would AMD-Vi do something similar (or
exactly the same) for group #s? Thanks,
Alex
Signed-off-by: Alex Williamson
On Tue, 2011-08-23 at 12:38 +1000, David Gibson wrote:
On Mon, Aug 22, 2011 at 09:45:48AM -0600, Alex Williamson wrote:
On Mon, 2011-08-22 at 15:55 +1000, David Gibson wrote:
On Sat, Aug 20, 2011 at 09:51:39AM -0700, Alex Williamson wrote:
We had an extremely productive VFIO BoF
On Tue, 2011-08-23 at 16:54 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2011-08-22 at 17:52 -0700, aafabbri wrote:
I'm not following you.
You have to enforce group/iommu domain assignment whether you have the
existing uiommu API, or if you change it to your proposed
On Tue, 2011-08-23 at 15:14 +0200, Roedel, Joerg wrote:
On Mon, Aug 22, 2011 at 03:17:00PM -0400, Alex Williamson wrote:
On Mon, 2011-08-22 at 19:25 +0200, Joerg Roedel wrote:
I am in favour of /dev/vfio/$GROUP. If multiple devices should be
assigned to a guest, there can also
On Tue, 2011-08-23 at 10:33 -0700, Aaron Fabbri wrote:
On 8/23/11 10:01 AM, Alex Williamson alex.william...@redhat.com wrote:
On Tue, 2011-08-23 at 16:54 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2011-08-22 at 17:52 -0700, aafabbri wrote:
I'm not following you.
You have
On Tue, 2011-08-23 at 07:01 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2011-08-22 at 09:45 -0600, Alex Williamson wrote:
Yes, that's the idea. An open question I have towards the configuration
side is whether we might add iommu driver specific options to the
groups. For instance
On Mon, 2011-08-22 at 15:55 +1000, David Gibson wrote:
On Sat, Aug 20, 2011 at 09:51:39AM -0700, Alex Williamson wrote:
We had an extremely productive VFIO BoF on Monday. Here's my attempt to
capture the plan that I think we agreed to:
We need to address both the description
On Mon, 2011-08-22 at 19:25 +0200, Joerg Roedel wrote:
On Sat, Aug 20, 2011 at 12:51:39PM -0400, Alex Williamson wrote:
We had an extremely productive VFIO BoF on Monday. Here's my attempt to
capture the plan that I think we agreed to:
We need to address both the description
We had an extremely productive VFIO BoF on Monday. Here's my attempt to
capture the plan that I think we agreed to:
We need to address both the description and enforcement of device
groups. Groups are formed any time the iommu does not have resolution
between a set of devices. On x86, this
On Mon, 2011-08-08 at 11:28 +0300, Avi Kivity wrote:
On 08/03/2011 05:04 AM, David Gibson wrote:
I still don't understand the distinction you're making. We're saying
the group is owned by a given user or guest in the sense that no-one
else may use anything in the group (including host
On Fri, 2011-08-05 at 20:42 +1000, Benjamin Herrenschmidt wrote:
Right. In fact to try to clarify the problem for everybody, I think we
can distinguish two different classes of constraints that can
influence the grouping of devices:
1- Hard constraints. These are typically devices using the
On Tue, 2011-08-02 at 11:27 +1000, Benjamin Herrenschmidt wrote:
It's a shared address space. With a basic configuration on p7ioc for
example we have MMIO going from 3G to 4G (PCI side addresses). BARs
contain the normal PCI address there. But that 1G is divided in 128
segments of equal size
On Tue, 2011-08-02 at 22:58 +1000, Benjamin Herrenschmidt wrote:
Don't worry, it took me a while to get my head around the HW :-) SR-IOV
VFs will generally not have limitations like that no, but on the other
hand, they -will- still require 1 VF = 1 group, ie, you won't be able to
take a
On Tue, 2011-08-02 at 18:28 +1000, David Gibson wrote:
On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote:
On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
[snip]
On x86, the USB controllers don't typically live behind a PCIe-to-PCI
bridge, so don't suffer
On Tue, 2011-08-02 at 12:14 -0600, Alex Williamson wrote:
On Tue, 2011-08-02 at 18:28 +1000, David Gibson wrote:
On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote:
On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
[snip]
On x86, the USB controllers don't
On Tue, 2011-08-02 at 17:29 -0400, Konrad Rzeszutek Wilk wrote:
On Tue, Aug 02, 2011 at 09:34:58AM -0600, Alex Williamson wrote:
On Tue, 2011-08-02 at 22:58 +1000, Benjamin Herrenschmidt wrote:
Don't worry, it took me a while to get my head around the HW :-) SR-IOV
VFs will generally
On Sun, 2011-07-31 at 08:21 +1000, Benjamin Herrenschmidt wrote:
On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
Hi folks !
So I promised Anthony I would try to summarize some of the comments
issues we have vs. VFIO after we've tried to use it for PCI pass-through
on
On Sun, 2011-07-31 at 09:54 +1000, Benjamin Herrenschmidt wrote:
On Sat, 2011-07-30 at 12:20 -0600, Alex Williamson wrote:
On x86, the USB controllers don't typically live behind a PCIe-to-PCI
bridge, so don't suffer the source identifier problem, but they do often
share an interrupt
On Sun, 2011-07-31 at 17:09 +0300, Avi Kivity wrote:
On 07/30/2011 02:58 AM, Benjamin Herrenschmidt wrote:
Due to our paravirt nature, we don't need to masquerade the MSI-X table
for example. At all. If the guest configures crap into it, too bad, it
can only shoot itself in the foot since
On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
Hi folks !
So I promised Anthony I would try to summarize some of the comments
issues we have vs. VFIO after we've tried to use it for PCI pass-through
on POWER. It's pretty long, there are various items with more or less
301 - 358 of 358 matches
Mail list logo
