Re: [dm-devel] AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0

2015-10-09 Thread Andreas Hartmann
On 10/09/2015 at 07:20 AM, Andreas Hartmann wrote: > On 10/08/2015 at 09:52 PM, Andreas Hartmann wrote: >> On 10/08/2015 at 08:21 PM, Andreas Hartmann wrote: >>> Am 08.10.2015 um 18:39 schrieb Joerg Roedel: On Wed, Oct 07, 2015 at 06:52:58PM +0200, Andreas Hartmann wrote: > To reproduce

Re: [PATCH v4 3/6] iommu: add ARM short descriptor page table allocator.

2015-10-09 Thread Will Deacon
On Tue, Sep 22, 2015 at 03:12:47PM +0100, Yong Wu wrote: > I would like to show you a problem I met, The recursion here may > lead to stack overflow while we test FHD video decode. > > From the log, I get the internal variable in the error case: the > "size" is 0x10, the "iova" is

Re: [dm-devel] AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0

2015-10-09 Thread Joerg Roedel
On Thu, Oct 08, 2015 at 09:47:28PM +0200, Andreas Hartmann wrote: > Got it. I attached the complete oops and the output of objdump. > > Kernel was linux 4.3-rc4 > > > This time, the oops was caused by the second PCI card I'm passing > through to another VM (the ath9k card worked fine this time

Re: [PATCH v4 3/6] iommu: add ARM short descriptor page table allocator.

2015-10-09 Thread Robin Murphy
On 09/10/15 16:57, Will Deacon wrote: On Tue, Sep 22, 2015 at 03:12:47PM +0100, Yong Wu wrote: I would like to show you a problem I met, The recursion here may lead to stack overflow while we test FHD video decode. From the log, I get the internal variable in the error case: the

Re: [PATCH] iommu/amd: Fix NULL pointer deref on device detach READ FPDMA QUEUED errors since Linux 4.0

2015-10-09 Thread Andreas Hartmann
Hello Jörg, On 10/09/2015 at 04:45 PM, Joerg Roedel wrote: > Hi Andreas, > > On Thu, Oct 08, 2015 at 09:47:28PM +0200, Andreas Hartmann wrote: >> This time, the oops was caused by the second PCI card I'm passing >> through to another VM (the ath9k card worked fine this time - chance?). >> I

Re: [dm-devel] AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0

2015-10-09 Thread Andreas Hartmann
Hello Jörg, On 10/09/2015 at 04:59 PM, Joerg Roedel wrote: > On Fri, Oct 09, 2015 at 11:15:05AM +0200, Andreas Hartmann wrote: >> v4.3-rc4 isn't usable at all for me as long as is hangs the machine on >> the necessary PCI passthrough for VMs (I need them). > > If the fix I just sent you works,

[RFC PATCH 2/2] vfio: Include no-iommu mode

2015-10-09 Thread Alex Williamson
There is really no way to safely give a user full access to a PCI without an IOMMU to protect the host from errant DMA. There is also no way to provide DMA translation, for use cases such as devices assignment to virtual machines. However, there are still those users that want userspace drivers

Re: [PATCH v4 3/6] iommu: add ARM short descriptor page table allocator.

2015-10-09 Thread Will Deacon
On Fri, Oct 09, 2015 at 06:41:51PM +0100, Robin Murphy wrote: > On 09/10/15 16:57, Will Deacon wrote: > >On Tue, Sep 22, 2015 at 03:12:47PM +0100, Yong Wu wrote: > >> I would like to show you a problem I met, The recursion here may > >>lead to stack overflow while we test FHD video decode. >

[RFC PATCH 1/2] vfio: Move vfio.c vfio_core.c

2015-10-09 Thread Alex Williamson
This allows us to more easily create a "vfio" module that includes multiple files. No code change, rename and Makefile update only. Signed-off-by: Alex Williamson --- drivers/vfio/Makefile|1 drivers/vfio/vfio.c | 1640

[RFC PATCH 0/2] VFIO no-iommu

2015-10-09 Thread Alex Williamson
Recent patches for UIO have been attempting to add MSI/X support, which unfortunately implies DMA support, which users have been enabling anyway, but was never intended for UIO. VFIO on the other hand expects an IOMMU to provide isolation of devices, but provides a much more complete device

Re: [RFC PATCH 1/2] vfio: Move vfio.c vfio_core.c

2015-10-09 Thread Greg KH
On Fri, Oct 09, 2015 at 12:41:03PM -0600, Alex Williamson wrote: > This allows us to more easily create a "vfio" module that includes > multiple files. No code change, rename and Makefile update only. > > Signed-off-by: Alex Williamson > --- > drivers/vfio/Makefile

[PATCH] iommu/amd: Fix NULL pointer deref on device detach READ FPDMA QUEUED errors since Linux 4.0

2015-10-09 Thread Joerg Roedel
Hi Andreas, On Thu, Oct 08, 2015 at 09:47:28PM +0200, Andreas Hartmann wrote: > This time, the oops was caused by the second PCI card I'm passing > through to another VM (the ath9k card worked fine this time - chance?). > I added the lspci output to the attached file, too. I digged a little bit

BUG: unable to handle kernel paging request with v4.3-rc4

2015-10-09 Thread Joerg Roedel
Hi Alex, while playing around with attaching a 32bit PCI device to a guest via VFIO I triggered this oops: [ 192.289917] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [ 192.298245] BUG: unable to handle kernel paging request at 880224582608 [ 192.306195] IP: []

Re: [dm-devel] AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0

2015-10-09 Thread Joerg Roedel
On Fri, Oct 09, 2015 at 11:15:05AM +0200, Andreas Hartmann wrote: > v4.3-rc4 isn't usable at all for me as long as is hangs the machine on > the necessary PCI passthrough for VMs (I need them). If the fix I just sent you works, could you please test this again with a (patched) v4.3-rc4 kernel?

Re: BUG: unable to handle kernel paging request with v4.3-rc4

2015-10-09 Thread Alex Williamson
On Fri, 2015-10-09 at 16:58 +0200, Joerg Roedel wrote: > Hi Alex, > > while playing around with attaching a 32bit PCI device to a guest via > VFIO I triggered this oops: > > [ 192.289917] kernel tried to execute NX-protected page - exploit attempt? > (uid: 0) > [ 192.298245] BUG: unable to

Re: BUG: unable to handle kernel paging request with v4.3-rc4

2015-10-09 Thread Joerg Roedel
On Fri, Oct 09, 2015 at 09:30:40AM -0600, Alex Williamson wrote: > I have not seen this one yet. There literally have been no changes for > vfio in 4.3, so if this is new, it may be collateral from changes > elsewhere. 32bit devices really shouldn't make any difference to vfio, > I'll see if I