similar to: [PATCH] Revert "vring: Force use of DMA API for ARM-based systems with legacy devices"

By forcing on DMA API usage for ARM systems, we have inadvertently kicked open a hornets' nest in terms of cache-coherency. Namely that unless the virtio device is explicitly described as capable of coherent DMA by firmware, the DMA APIs on ARM and other DT-based platforms will assume it is non-coherent. This turns out to cause a big problem for the likes of QEMU and kvmtool, which generate

By forcing on DMA API usage for ARM systems, we have inadvertently kicked open a hornets' nest in terms of cache-coherency. Namely that unless the virtio device is explicitly described as capable of coherent DMA by firmware, the DMA APIs on ARM and other DT-based platforms will assume it is non-coherent. This turns out to cause a big problem for the likes of QEMU and kvmtool, which generate

On Thu, Feb 09, 2017 at 06:31:18PM +0000, Will Deacon wrote: > On Thu, Feb 09, 2017 at 08:17:16PM +0200, Michael S. Tsirkin wrote: > > On Thu, Feb 02, 2017 at 04:40:49PM +0000, Will Deacon wrote: > > > On Thu, Feb 02, 2017 at 06:30:28PM +0200, Michael S. Tsirkin wrote: > > > > I am inclined to say, for 4.10 let's revert > > > >

On Thu, Feb 09, 2017 at 06:31:18PM +0000, Will Deacon wrote: > On Thu, Feb 09, 2017 at 08:17:16PM +0200, Michael S. Tsirkin wrote: > > On Thu, Feb 02, 2017 at 04:40:49PM +0000, Will Deacon wrote: > > > On Thu, Feb 02, 2017 at 06:30:28PM +0200, Michael S. Tsirkin wrote: > > > > I am inclined to say, for 4.10 let's revert > > > >

On 20/01/17 10:33, Will Deacon wrote: > On Thu, Jan 19, 2017 at 11:51:06PM +0200, Michael S. Tsirkin wrote: >> On Mon, Jan 16, 2017 at 02:34:08PM +0000, Will Deacon wrote: >>> On Mon, Jan 16, 2017 at 04:27:28PM +0200, Michael S. Tsirkin wrote: >>>> On Mon, Jan 16, 2017 at 02:21:03PM +0000, Will Deacon wrote: >>>>> On Mon, Jan 16, 2017 at 04:18:03PM

On 20/01/17 10:33, Will Deacon wrote: > On Thu, Jan 19, 2017 at 11:51:06PM +0200, Michael S. Tsirkin wrote: >> On Mon, Jan 16, 2017 at 02:34:08PM +0000, Will Deacon wrote: >>> On Mon, Jan 16, 2017 at 04:27:28PM +0200, Michael S. Tsirkin wrote: >>>> On Mon, Jan 16, 2017 at 02:21:03PM +0000, Will Deacon wrote: >>>>> On Mon, Jan 16, 2017 at 04:18:03PM

On Thu, Feb 02, 2017 at 04:40:49PM +0000, Will Deacon wrote: > On Thu, Feb 02, 2017 at 06:30:28PM +0200, Michael S. Tsirkin wrote: > > I am inclined to say, for 4.10 let's revert > > c7070619f3408d9a0dffbed9149e6f00479cf43b since what it fixes is not a > > regression in 4.10. > > No complaints there, as long as we can keep working to fix this for 4.11 > and

On Thu, Feb 02, 2017 at 04:40:49PM +0000, Will Deacon wrote: > On Thu, Feb 02, 2017 at 06:30:28PM +0200, Michael S. Tsirkin wrote: > > I am inclined to say, for 4.10 let's revert > > c7070619f3408d9a0dffbed9149e6f00479cf43b since what it fixes is not a > > regression in 4.10. > > No complaints there, as long as we can keep working to fix this for 4.11 > and

On Wed, Feb 01, 2017 at 12:25:57PM +0000, Robin Murphy wrote: > By forcing on DMA API usage for ARM systems, we have inadvertently > kicked open a hornets' nest in terms of cache-coherency. Namely that > unless the virtio device is explicitly described as capable of coherent > DMA by firmware, the DMA APIs on ARM and other DT-based platforms will > assume it is non-coherent.

On Wed, Feb 01, 2017 at 12:25:57PM +0000, Robin Murphy wrote: > By forcing on DMA API usage for ARM systems, we have inadvertently > kicked open a hornets' nest in terms of cache-coherency. Namely that > unless the virtio device is explicitly described as capable of coherent > DMA by firmware, the DMA APIs on ARM and other DT-based platforms will > assume it is non-coherent.

Booting Linux on an ARM fastmodel containing an SMMU emulation results in an unexpected I/O page fault from the legacy virtio-blk PCI device: [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received: [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010 [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000 [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002 [

Booting Linux on an ARM fastmodel containing an SMMU emulation results in an unexpected I/O page fault from the legacy virtio-blk PCI device: [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received: [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010 [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000 [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002 [

On Mon, Jan 16, 2017 at 02:34:08PM +0000, Will Deacon wrote: > On Mon, Jan 16, 2017 at 04:27:28PM +0200, Michael S. Tsirkin wrote: > > On Mon, Jan 16, 2017 at 02:21:03PM +0000, Will Deacon wrote: > > > On Mon, Jan 16, 2017 at 04:18:03PM +0200, Michael S. Tsirkin wrote: > > > > On Mon, Jan 16, 2017 at 10:40:28AM +0000, Will Deacon wrote: > > > > > On

On Mon, Jan 16, 2017 at 02:34:08PM +0000, Will Deacon wrote: > On Mon, Jan 16, 2017 at 04:27:28PM +0200, Michael S. Tsirkin wrote: > > On Mon, Jan 16, 2017 at 02:21:03PM +0000, Will Deacon wrote: > > > On Mon, Jan 16, 2017 at 04:18:03PM +0200, Michael S. Tsirkin wrote: > > > > On Mon, Jan 16, 2017 at 10:40:28AM +0000, Will Deacon wrote: > > > > > On

Whilst always using the DMA API is OK on ARM systems in most cases, there can be a problem if a hypervisor fails to tell its guest that a virtio device is cache-coherent. In that case, the guest will end up making non-cacheable mappings for DMA buffers (i.e. the vring), which, if the host is using a cacheable view of the same buffer on the other end, is not a recipe for success. It turns out that

Whilst always using the DMA API is OK on ARM systems in most cases, there can be a problem if a hypervisor fails to tell its guest that a virtio device is cache-coherent. In that case, the guest will end up making non-cacheable mappings for DMA buffers (i.e. the vring), which, if the host is using a cacheable view of the same buffer on the other end, is not a recipe for success. It turns out that

On Tue, Jan 24, 2017 at 04:04:11PM +0000, Marc Zyngier wrote: > On 20/01/17 10:33, Will Deacon wrote: > > On Thu, Jan 19, 2017 at 11:51:06PM +0200, Michael S. Tsirkin wrote: > >> On Mon, Jan 16, 2017 at 02:34:08PM +0000, Will Deacon wrote: > >>> On Mon, Jan 16, 2017 at 04:27:28PM +0200, Michael S. Tsirkin wrote: > >>>> On Mon, Jan 16, 2017 at 02:21:03PM

On Thu, Feb 09, 2017 at 06:31:18PM +0000, Will Deacon wrote: > On ARM (and other archs such as > Power), having a mismatch between a cacheable and a non-cacheable mapping > can result in a loss of coherency between the two (for example, if the > non-cacheable gues accesses bypass the cache, but the cacheable host > accesses allocate in the cache). I guess it's an optimization

On Thu, Feb 09, 2017 at 06:31:18PM +0000, Will Deacon wrote: > On ARM (and other archs such as > Power), having a mismatch between a cacheable and a non-cacheable mapping > can result in a loss of coherency between the two (for example, if the > non-cacheable gues accesses bypass the cache, but the cacheable host > accesses allocate in the cache). I guess it's an optimization

On Thu, Feb 02, 2017 at 01:34:03PM +0000, Robin Murphy wrote: > On 02/02/17 11:26, Will Deacon wrote: > > On Wed, Feb 01, 2017 at 09:19:22PM +0200, Michael S. Tsirkin wrote: > >> On Wed, Feb 01, 2017 at 06:27:09PM +0000, Will Deacon wrote: > >>> On Wed, Feb 01, 2017 at 08:09:21PM +0200, Michael S. Tsirkin wrote: > >>>> I'd like to do that instead.