[PATCH 04/18] alpha: Override READ_ONCE() with barriered implementation

Rather then relying on the core code to use smp_read_barrier_depends() as part of the READ_ONCE() definition, instead override __READ_ONCE() in the Alpha code so that it is treated the same way as smp_load_acquire(). Acked-by: Paul E. McKenney Signed-off-by: Will Deacon --- arch/alpha/include

[PATCH 01/18] tools: bpf: Use local copy of headers including uapi/linux/filter.h

. Cc: Alexei Starovoitov Cc: Masahiro Yamada Suggested-by: Daniel Borkmann Reported-by: Xiao Yang Signed-off-by: Will Deacon --- tools/bpf/Makefile| 3 +- tools/include/uapi/linux/filter.h | 90 +++ 2 files changed, 92 insertions(+), 1 deletion

[PATCH 03/18] asm/rwonce: Allow __READ_ONCE to be overridden by the architecture

required. Acked-by: Paul E. McKenney Signed-off-by: Will Deacon --- include/asm-generic/rwonce.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h index 92cc2f223cb3..f9dfa88fc04d 100644 --- a/include/asm-generic/rwonce.h +++ b/include

Re: [RFC/PATCH 1/1] virtio: Introduce MMIO ops

On Thu, Apr 30, 2020 at 04:04:46PM +0530, Srivatsa Vaddagiri wrote: > * Will Deacon [2020-04-30 11:14:32]: > > > > +#ifdef CONFIG_VIRTIO_MMIO_OPS > > > > > > +static struct virtio_mmio_ops *mmio_ops; > > > + > > > +#define virtio_readb(a

Re: [RFC/PATCH 0/1] virtio_mmio: hypervisor specific interfaces for MMIO

Hi Vatsa, On Thu, Apr 30, 2020 at 03:59:39PM +0530, Srivatsa Vaddagiri wrote: > * Will Deacon [2020-04-30 11:08:22]: > > > > This patch is meant to seek comments. If its considered to be in right > > > direction, will work on making it more complete and send the next

Re: [RFC/PATCH 1/1] virtio: Introduce MMIO ops

On Thu, Apr 30, 2020 at 03:32:56PM +0530, Srivatsa Vaddagiri wrote: > Some hypervisors may not support MMIO transport i.e trap config > space access and have it be handled by backend driver. They may > allow other ways to interact with backend such as message-queue > or doorbell API. This patch

Re: [RFC/PATCH 0/1] virtio_mmio: hypervisor specific interfaces for MMIO

On Thu, Apr 30, 2020 at 03:32:55PM +0530, Srivatsa Vaddagiri wrote: > The Type-1 hypervisor we are dealing with does not allow for MMIO transport. > [1] summarizes some of the problems we have in making virtio work on such > hypervisors. This patch proposes a solution for transport problem viz

Re: [PATCH 00/14] iommu: Move iommu_fwspec out of 'struct device'

0 (arm-smmu) and it seems to work the same as before, so: Tested-by: Will Deacon # arm-smmu I'll try to review the patches soon. Cheers, Will ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 0/6] KVM: arm64: VCPU preempted check support

[+PeterZ] On Thu, Dec 26, 2019 at 09:58:27PM +0800, Zengruan Ye wrote: > This patch set aims to support the vcpu_is_preempted() functionality > under KVM/arm64, which allowing the guest to obtain the VCPU is > currently running or not. This will enhance lock performance on > overcommitted hosts

Re: [PATCH v2 2/5] iommu: arm: Use iommu_put_resv_regions_simple()

On Mon, Dec 09, 2019 at 03:50:04PM +0100, Thierry Reding wrote: > From: Thierry Reding > > Use the new standard function instead of open-coding it. > > Cc: Will Deacon > Cc: Robin Murphy > Signed-off-by: Thierry Reding > --- > drivers/iommu/arm-smmu-v3.c | 11 +

Re: [PATCH 01/13] compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h

On Mon, Nov 11, 2019 at 10:32:46AM +0100, Arnd Bergmann wrote: > On Mon, Nov 11, 2019 at 9:10 AM Christian Borntraeger > wrote: > > On 08.11.19 20:57, Arnd Bergmann wrote: > > > On Fri, Nov 8, 2019 at 6:01 PM Will Deacon wrote: > > >> > > >> In pre

[PATCH 13/13] checkpatch: Remove checks relating to [smp_]read_barrier_depends()

The '[smp_]read_barrier_depends()' macros no longer exist, so we don't need to deal with them in the checkpatch script. Signed-off-by: Will Deacon --- scripts/checkpatch.pl | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl

[PATCH 12/13] include/linux: Remove smp_read_barrier_depends() from comments

'smp_read_barrier_depends()' doesn't exist any more, so reword the two comments that mention it to refer to "dependency ordering" instead. Signed-off-by: Will Deacon --- include/linux/percpu-refcount.h | 2 +- include/linux/ptr_ring.h| 2 +- 2 files changed, 2 insertions(+), 2

[PATCH 08/13] locking/barriers: Remove definitions for [smp_]read_barrier_depends()

There are no remaining users of '[smp_]read_barrier_depends()', so remove it from the generic implementation of 'barrier.h'. Signed-off-by: Will Deacon --- include/asm-generic/barrier.h | 17 - 1 file changed, 17 deletions(-) diff --git a/include/asm-generic/barrier.h b/include

[PATCH 11/13] powerpc: Remove comment about read_barrier_depends()

'read_barrier_depends()' doesn't exist anymore so stop talking about it. Signed-off-by: Will Deacon --- arch/powerpc/include/asm/barrier.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/include/asm/barrier.h b/arch/powerpc/include/asm/barrier.h index fbe8df433019

[PATCH 09/13] Documentation/barriers: Remove references to [smp_]read_barrier_depends()

rriers.txt' as it doesn't make any sense now that the dependency barriers have been removed. Signed-off-by: Will Deacon --- .../RCU/Design/Requirements/Requirements.html | 11 +- Documentation/memory-barriers.txt | 156 +- 2 files changed, 13 insertions(+), 154 deletion

[PATCH 07/13] alpha: Replace smp_read_barrier_depends() usage with smp_[r]mb()

In preparation for removing 'smp_read_barrier_depends()' altogether, move the Alpha code over to using 'smp_rmb()' and 'smp_mb()' directly. Signed-off-by: Will Deacon --- arch/alpha/include/asm/atomic.h | 16 arch/alpha/include/asm/pgtable.h | 10 +- mm/memory.c

[PATCH 06/13] READ_ONCE: Remove smp_read_barrier_depends() invocation

Alpha overrides '__read_once_size_n()' directly, so there's no need to use 'smp_read_barrier_depends()' in the core code. Signed-off-by: Will Deacon --- include/asm-generic/rwonce.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h

[PATCH 10/13] tools/memory-model: Remove smp_read_barrier_depends() from informal doc

'smp_read_barrier_depends()' has gone the way of mmiowb() and so many esoteric memory barriers before it. Drop the two mentions of this deceased barrier from the LKMM informal explanation document. Signed-off-by: Will Deacon --- .../Documentation/explanation.txt | 26

[PATCH 05/13] alpha: Override READ_ONCE() with barriered implementation

Rather then relying on the core code to use 'smp_read_barrier_depends()' as part of the 'READ_ONCE()' definition, instead override 'READ_ONCE()' in the Alpha code so that it is treated the same way as 'smp_load_acquire()'. Signed-off-by: Will Deacon --- arch/alpha/include/asm/barrier.h | 61

[PATCH 01/13] compiler.h: Split {READ, WRITE}_ONCE definitions out into rwonce.h

In preparation for allowing architectures to define their own implementation of the 'READ_ONCE()' macro, move the generic '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h' and into a new 'rwonce.h' header under 'asm-generic'. Signed-off-by: Will Deacon --- include/asm

[PATCH 00/13] Finish off [smp_]read_barrier_depends()

on Wang Cc: Arnd Bergmann Cc: Joe Perches Cc: Boqun Feng Cc: linux-al...@vger.kernel.org Cc: virtualization@lists.linux-foundation.org --->8 Will Deacon (13): compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h READ_ONCE: Undefine internal __READ_ONCE_SIZE macro after use

[PATCH 02/13] READ_ONCE: Undefine internal __READ_ONCE_SIZE macro after use

The '__READ_ONCE_SIZE()' macro is only used as part of building 'READ_ONCE()', so undefine it once we don't need it anymore. Signed-off-by: Will Deacon --- include/asm-generic/rwonce.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/asm-generic/rwonce.h b/include/asm-generic

[PATCH 03/13] READ_ONCE: Allow __READ_ONCE_SIZE cases to be overridden by the architecture

required. Signed-off-by: Will Deacon --- include/asm-generic/rwonce.h | 28 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h index abf326634ecd..2c2ac0948c94 100644 --- a/include/asm-generic

[PATCH 04/13] vhost: Remove redundant use of read_barrier_depends() barrier

any writing to | indirect->addr after avail idx is increased Remove the redundant barrier invocation. Suggested-by: Jason Wang Signed-off-by: Will Deacon --- drivers/vhost/vhost.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index 36

Re: read_barrier_depends() usage in vhost.c

Hi Jason, On Mon, Oct 21, 2019 at 01:48:53PM +0800, Jason Wang wrote: > On 2019/10/19 上午4:58, Will Deacon wrote: > > Staring at the code some more, my best bet at the moment > > is that the load of 'indirect->addr' is probably the one to worry about, > > since it's p

Re: read_barrier_depends() usage in vhost.c

On Thu, Oct 17, 2019 at 10:17:18AM +0800, Jason Wang wrote: > On 2019/10/17 上午7:33, Will Deacon wrote: > > In an attempt to remove the remaining traces of [smp_]read_barrier_depends() > > following my previous patches to strengthen READ_ONCE() for Alpha [1], I > > ended

Re: read_barrier_depends() usage in vhost.c

[Bah: I typoed the LKML address, so I've fixed it for this one] On Thu, Oct 17, 2019 at 12:33:40AM +0100, Will Deacon wrote: > Hi all, > > In an attempt to remove the remaining traces of [smp_]read_barrier_depends() > following my previous patches to strengthen READ_ONCE() for

read_barrier_depends() usage in vhost.c

Hi all, In an attempt to remove the remaining traces of [smp_]read_barrier_depends() following my previous patches to strengthen READ_ONCE() for Alpha [1], I ended up trying to decipher the read_barrier_depends() usage in the vhost driver: --->8 // drivers/vhost/vhost.c static int

Re: [PATCH 1/5] iommu: Implement iommu_put_resv_regions_simple()

On Thu, Aug 29, 2019 at 01:17:48PM +0200, Thierry Reding wrote: > From: Thierry Reding > > Implement a generic function for removing reserved regions. This can be > used by drivers that don't do anything fancy with these regions other > than allocating memory for them. > > Signed-off-by:

Re: [PATCH v2] vhost: block speculation of translated descriptors

On Wed, Sep 11, 2019 at 09:52:25AM -0400, Michael S. Tsirkin wrote: > On Wed, Sep 11, 2019 at 08:10:00AM -0400, Michael S. Tsirkin wrote: > > iovec addresses coming from vhost are assumed to be > > pre-validated, but in fact can be speculated to a value > > out of range. > > > > Userspace address

Re: [PATCH] MAINTAINERS: Update my email address

On Mon, Jul 22, 2019 at 02:44:40PM +0100, Jean-Philippe Brucker wrote: > Update MAINTAINERS and .mailmap with my @linaro.org address, since I > don't have access to my @arm.com address anymore. > > Signed-off-by: Jean-Philippe Brucker > --- > .mailmap| 1 + > MAINTAINERS | 2 +- > 2 files

Re: [PATCH RFC 2/4] include/linux/compiler.h: allow memory operands

On Wed, Jan 02, 2019 at 03:57:54PM -0500, Michael S. Tsirkin wrote: > We don't really care whether the variable is in-register > or in-memory. Relax the constraint accordingly. > > Signed-off-by: Michael S. Tsirkin > --- > include/linux/compiler.h | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [RFC 0/4] Virtio uses DMA API for all devices

Hi Michael, On Sun, Aug 05, 2018 at 03:27:42AM +0300, Michael S. Tsirkin wrote: > On Wed, Aug 01, 2018 at 09:16:38AM +0100, Will Deacon wrote: > > On Tue, Jul 31, 2018 at 03:36:22PM -0500, Benjamin Herrenschmidt wrote: > > > On Tue, 2018-07-31 at 10:30 -0700, Chris

Re: [RFC 0/4] Virtio uses DMA API for all devices

Hi Christoph, On Wed, Aug 01, 2018 at 01:36:39AM -0700, Christoph Hellwig wrote: > On Wed, Aug 01, 2018 at 09:16:38AM +0100, Will Deacon wrote: > > On arm/arm64, the problem we have is that legacy virtio devices on the MMIO > > transport (so definitely not PCI) have historically

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Tue, Jul 31, 2018 at 03:36:22PM -0500, Benjamin Herrenschmidt wrote: > On Tue, 2018-07-31 at 10:30 -0700, Christoph Hellwig wrote: > > > However the question people raise is that DMA API is already full of > > > arch-specific tricks the likes of which are outlined in your post linked > > >

Re: [RFC 0/4] Virtio uses DMA API for all devices

arm64, which in turn means that we can enable the SMMU with legacy devices in our fastmodel emulation platform (which is slowly being upgraded to virtio 1.0) without hanging during boot. Patch below. So: Acked-by: Will Deacon Tested-by: Will Deacon Thanks! Will --->8 >From 4ef39e9de2c

Re: [PATCH] virtio: Try to untangle DMA coherency

On Fri, Feb 10, 2017 at 07:16:10PM +0200, Michael S. Tsirkin wrote: > On Thu, Feb 09, 2017 at 06:31:18PM +, 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 cohe

Re: [PATCH] virtio: Try to untangle DMA coherency

On Thu, Feb 09, 2017 at 08:49:41PM +0200, Michael S. Tsirkin wrote: > On Thu, Feb 09, 2017 at 06:31:18PM +, 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 +, Will Deacon wrote: > >

Re: [PATCH] virtio: Try to untangle DMA coherency

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

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

each other and things going horribly wrong. > > We are working on a safer work-around. > > Fixes: c7070619f340 ("vring: Force use of DMA API for ARM-based systems with > legacy devices") > Reported-by: Robin Murphy <robin.mur...@arm.com> > Cc: <sta...@vger.kernel

Re: [PATCH v2 2/2] virtio: Document DMA coherency

14,4 +24,5 @@ Example: > compatible = "virtio,mmio"; > reg = <0x3000 0x100>; > interrupts = <41>; > + dma-coherent; I think this is a sensible update to the binding and is independent of whatever we decide

Re: [PATCH] virtio: Try to untangle DMA coherency

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 onwards.

Re: [PATCH] virtio: Try to untangle DMA coherency

On Wed, Feb 01, 2017 at 09:19:22PM +0200, Michael S. Tsirkin wrote: > On Wed, Feb 01, 2017 at 06:27:09PM +, Will Deacon wrote: > > On Wed, Feb 01, 2017 at 08:09:21PM +0200, Michael S. Tsirkin wrote: > > > I'd like to do that instead. It's fastboot doing the unreasonabl

Re: [PATCH] virtio: Try to untangle DMA coherency

MMU_PLATFORM is advertised by the device (which is what I suggested in my reply). We can't detect the fastmodel, but we could implicitly treat virtio-mmio devices as cache-coherent regardless of the "dma-coherent" flag. I already prototyped this, but I suspect the devicetree people will p

Re: [PATCH] virtio: Try to untangle DMA coherency

On Wed, Feb 01, 2017 at 12:25:57PM +, 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

Re: [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems

On Thu, Jan 19, 2017 at 11:51:06PM +0200, Michael S. Tsirkin wrote: > On Mon, Jan 16, 2017 at 02:34:08PM +, 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 +, Will Deacon wrote: > >

Re: [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems

On Mon, Jan 16, 2017 at 04:27:28PM +0200, Michael S. Tsirkin wrote: > On Mon, Jan 16, 2017 at 02:21:03PM +, 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 +, Will Deacon wrote: > >

Re: [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems

On Mon, Jan 16, 2017 at 04:18:03PM +0200, Michael S. Tsirkin wrote: > On Mon, Jan 16, 2017 at 10:40:28AM +, Will Deacon wrote: > > On Fri, Jan 13, 2017 at 08:23:35PM +0200, Michael S. Tsirkin wrote: > > > On Fri, Jan 13, 2017 at 05:21:54PM +, Will Deacon wrote: > >

Re: [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems

On Fri, Jan 13, 2017 at 08:23:35PM +0200, Michael S. Tsirkin wrote: > On Fri, Jan 13, 2017 at 05:21:54PM +, Will Deacon wrote: > > On Fri, Jan 13, 2017 at 06:46:32PM +0200, Michael S. Tsirkin wrote: > > > On Fri, Jan 13, 2017 at 09:25:22AM +, Will Deacon wrote: > >

Re: [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems

On Fri, Jan 13, 2017 at 06:46:32PM +0200, Michael S. Tsirkin wrote: > On Fri, Jan 13, 2017 at 09:25:22AM +, Will Deacon wrote: > > On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote: > > > On Wed, Jan 11, 2017 at 10:01:39AM +, Will Deacon wrote: > >

Re: [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems

On Wed, Jan 11, 2017 at 10:12:36AM -0800, Andy Lutomirski wrote: > On Wed, Jan 11, 2017 at 2:01 AM, Will Deacon <will.dea...@arm.com> wrote: > > On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote: > >> On Tue, Jan 10, 2017 at 05:51:18PM +, Robin M

Re: [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems

On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote: > On Wed, Jan 11, 2017 at 10:01:39AM +, Will Deacon wrote: > > On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote: > > > On Tue, Jan 10, 2017 at 05:51:18PM +, Robin Murphy wrote: > &g

Re: [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems

On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote: > On Tue, Jan 10, 2017 at 05:51:18PM +, Robin Murphy wrote: > > From: Will Deacon <will.dea...@arm.com> > > > > Booting Linux on an ARM fastmodel containing an SMMU emulation results > > in

Re: [RFC PATCH] vring: Force use of DMA API for ARM-based systems

On Mon, Jan 09, 2017 at 11:24:04AM +, Robin Murphy wrote: > On 06/01/17 21:51, Andy Lutomirski wrote: > > On Fri, Jan 6, 2017 at 10:32 AM, Robin Murphy wrote: > >> On 06/01/17 17:48, Jean-Philippe Brucker wrote: > >>> It used to work with 4.9, but since 9491ae4 ("mm:

Re: [RFC PATCH] vring: Force use of DMA API for ARM-based systems

Hi Jean-Philippe, On Fri, Jan 06, 2017 at 05:48:33PM +, Jean-Philippe Brucker wrote: > On 20/12/16 15:14, Will Deacon wrote: > > Booting Linux on an ARM fastmodel containing an SMMU emulation results > > in an unexpected I/O page fault from the legacy virtio

[RFC PATCH] vring: Force use of DMA API for ARM-based systems

described by firmware tables such as device-tree or IORT), then we can safely use the DMA API for all virtio devices. Cc: Andy Lutomirski <l...@kernel.org> Cc: Michael S. Tsirkin <m...@redhat.com> Signed-off-by: Will Deacon <will.dea...@arm.com> --- drivers/virtio/virtio_ring.

Re: VIRTIO_F_IOMMU_PLATFORM

On Fri, Oct 07, 2016 at 07:24:34AM +0300, Michael S. Tsirkin wrote: > On Tue, Sep 27, 2016 at 09:57:14AM +0100, Will Deacon wrote: > > Hi Michael, > > > > In commit 1a937693993f ("virtio: new feature to detect IOMMU device quirk"), > > you added a new

VIRTIO_F_IOMMU_PLATFORM

Hi Michael, In commit 1a937693993f ("virtio: new feature to detect IOMMU device quirk"), you added a new feature bit (VIRTIO_F_IOMMU_PLATFORM) to describe whether or not a given virtio device requires physical address or bus addresses. Is there a plan to get this incorporated into the virtio

[PATCH v3] virtio_pci: Limit DMA mask to 44 bits for legacy virtio devices

min Serebrin <sereb...@google.com> Signed-off-by: Will Deacon <will.dea...@arm.com> --- drivers/virtio/virtio_pci_legacy.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/virtio/virtio_pci_legacy.c b/drivers/virtio/virtio_pci_leg

Re: [PATCH v2] virtio_pci: Limit DMA mask to 44 bits for legacy virtio devices

Hi Michael, On Wed, Sep 14, 2016 at 03:42:25PM +0300, Michael S. Tsirkin wrote: > On Wed, Sep 14, 2016 at 12:16:28PM +0100, Will Deacon wrote: > > Legacy virtio defines the virtqueue base using a 32-bit PFN field, with > > a read-only register indicating a fixed page size of 4k. &g

[PATCH v2] virtio_pci: Limit DMA mask to 44 bits for legacy virtio devices

ebrin <sereb...@google.com> Signed-off-by: Will Deacon <will.dea...@arm.com> --- drivers/virtio/virtio_pci_legacy.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/virtio/virtio_pci_legacy.c b/drivers/virtio/virtio_pci_legacy.c index 8c4e61783

Re: [PATCH] virtio_pci: Limit DMA mask to 44 bits for legacy virtio devices

On Mon, Sep 12, 2016 at 06:33:43PM +0300, Michael S. Tsirkin wrote: > On Mon, Sep 12, 2016 at 01:10:41PM +0100, Will Deacon wrote: > > Legacy virtio defines the virtqueue base using a 32-bit PFN field, with > > a read-only register indicating a fixed page size of 4k. > >

[PATCH] virtio_pci: Limit DMA mask to 44 bits for legacy virtio devices

-bit, leading to IOMMU faults, failure to read from the queue or data corruption. This patch restricts the DMA mask for legacy PCI virtio devices to 44 bits, which matches the specification. Cc: Andy Lutomirski <l...@kernel.org> Cc: Michael S. Tsirkin <m...@redhat.com> Signed-off-by:

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 11:58:20AM -0800, Paul E. McKenney wrote: > On Tue, Jan 26, 2016 at 12:16:09PM +, Will Deacon wrote: > > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > > > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote: > >

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 11:32:00AM +0100, Peter Zijlstra wrote: > On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > > specification (I seem to keep repeating this). > > Do we want this ? > > --- >

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote: > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > > PPC Overlapping Group-B sets version 4 > > > "" &g

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Mon, Jan 25, 2016 at 05:06:46PM -0800, Paul E. McKenney wrote: > On Mon, Jan 25, 2016 at 02:41:34PM +, Will Deacon wrote: > > On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote: > > > On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote: >

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote: > On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote: > > On Fri, Jan 15, 2016 at 10:24:32AM +0000, Will Deacon wrote: > > > See my earlier reply [1] (but also, your WRC Linux example looks more &g

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > On Fri, Jan 15, 2016 at 10:27:14PM +0100, Peter Zijlstra wrote: > > On Fri, Jan 15, 2016 at 09:46:12AM -0800, Paul E. McKenney wrote: > > > On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote: > > > > > > And the stuff

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

eaker notion of transitivity: > The transitivity of full smp_mb() barriers is global, but that > of smp_store_release()/smp_load_acquire() chains is local. This > commit therefore introduces the notion of local transitivity and > gives an example. > >

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 02:55:10PM -0800, Paul E. McKenney wrote: > On Thu, Jan 14, 2016 at 01:36:50PM -0800, Leonid Yegoshin wrote: > > On 01/14/2016 01:29 PM, Paul E. McKenney wrote: > > > > > >>On 01/14/2016 12:34 PM, Paul E. McKenney wrote: > > >>> > > >>>The WRC+addr+addr is OK because data

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

Paul, On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote: > On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > It is not so simple, I mean "local ordering for address and data > > dependencies". Local ordering is NOT enough. It happens that current > > MIPS R6

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid Yegoshin wrote: > On 01/13/2016 12:48 PM, Peter Zijlstra wrote: > >On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote: > > > >>I ask HW team about it but I have a question - has it any relationship with > >>replacing MIPS SYNC with

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 12, 2016 at 12:45:14PM -0800, Leonid Yegoshin wrote: > >The issue I have with the SYNC description in the text above is that it > >describes the single CPU (program order) and the dual-CPU (confusingly > >named global order) cases, but then doesn't generalise any further. That > >means

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 12, 2016 at 11:40:12AM +0100, Peter Zijlstra wrote: > On Tue, Jan 12, 2016 at 11:25:55AM +0100, Peter Zijlstra wrote: > > On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > > > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > > > 0x12 semantics nor

Re: [PATCH] virtio_ring: use smp_store_mb

On Thu, Dec 17, 2015 at 04:09:17PM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 04:34:57PM +0200, Michael S. Tsirkin wrote: > > On Thu, Dec 17, 2015 at 03:02:12PM +0100, Peter Zijlstra wrote: > > > > > commit 9e1a27ea42691429e31f158cce6fc61bc79bb2e9 > > > > Author:

Re: [PATCH] 9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers

On Wed, Dec 04, 2013 at 08:43:18PM +, Richard Yao wrote: The 9p-virtio transport does zero copy on things larger than 1024 bytes in size. It accomplishes this by returning the physical addresses of pages to the virtio-pci device. At present, the translation is usually a bit shift.

Re: [PATCH] 9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers

On Fri, Dec 06, 2013 at 02:38:28PM +, Richard Yao wrote: On 12/06/2013 06:14 AM, Will Deacon wrote: On Wed, Dec 04, 2013 at 08:43:18PM +, Richard Yao wrote: diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c index 9c5a1aa..5d1d04b 100644 --- a/net/9p/trans_virtio.c +++ b

[PATCH v2 1/3] mm: highmem: export kmap_to_page for modules

Some virtio device drivers (9p) need to translate high virtual addresses to physical addresses, which are inserted into the virtqueue for processing by userspace. This patch exports the kmap_to_page symbol, so that the affected drivers can be compiled as modules. Signed-off-by: Will Deacon

[PATCH v2 3/3] virtio: force vring descriptors to be allocated from lowmem

...@rustcorp.com.au Cc: Sasha Levin levinsasha...@gmail.com Signed-off-by: Will Deacon will.dea...@arm.com --- drivers/virtio/virtio_ring.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index e639584..286c30c

[PATCH v2 2/3] virtio: 9p: correctly pass physical address to userspace for high pages

the scatterlist with junk. This patch uses kmap_to_page when populating the page array for a kernel buffer. Cc: Rusty Russell ru...@rustcorp.com.au Cc: Sasha Levin levinsasha...@gmail.com Signed-off-by: Will Deacon will.dea...@arm.com --- net/9p/trans_virtio.c |3 ++- 1 files changed, 2 insertions

<    1   2