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'
file and into a new 'rwonce.h' header under 'asm-generic'.
Acked-by: Paul E.
those in the main source tree.
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
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
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
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
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
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 all
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 how
MMU-400 (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
[+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 (m
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 +
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
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/script
'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 i
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
'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
ind
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.
emory-barriers.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 in
'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
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/inc
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
--
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&#x
"Michael S. Tsirkin"
Cc: Jason 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 inte
ry barriers are also 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
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/rwonc
to the correct
| indirect->addr and driver are not expected to do 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(-
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
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 up t
[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()
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 get_indirect(s
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: Thierry
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
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 ch
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 dele
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
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
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
> > > above
y virtio devices on 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
On Fri, Feb 10, 2017 at 07:16:10PM +0200, Michael S. Tsirkin wrote:
> 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 cohe
On Thu, Feb 09, 2017 at 08:49:41PM +0200, Michael S. Tsirkin wrote:
> 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 +, 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
; 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
> Cc:
> Signed-off-by: Will Deacon
> Si
> 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 to do for IOMMUs and DMA on
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. You'
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. It's fastboot doing the unrea
set correctly when VIRTIO_F_IOMMU_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
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
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 +, 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 +, 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 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 08:23:35PM +0200, Michael S. Tsirkin wrote:
> On Fri, Jan 13, 2017 at 05:21:54PM +0000, 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:
> >
On Fri, Jan 13, 2017 at 06:46:32PM +0200, Michael S. Tsirkin wrote:
> On Fri, Jan 13, 2017 at 09:25:22AM +0000, 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:
> >
On Wed, Jan 11, 2017 at 10:12:36AM -0800, Andy Lutomirski wrote:
> On Wed, Jan 11, 2017 at 2:01 AM, 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:
> &
On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> On Wed, Jan 11, 2017 at 10:01:39AM +0000, 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
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
> >
> > Booting Linux on an ARM fastmodel containing an SMMU emulation results
> > in an unexpected I/O page fault
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: don't cap request size
> >
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
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
Cc: Michael S. Tsirkin
Signed-off-by: Will Deacon
---
drivers/virtio/virtio_ring.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/virtio
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 fea
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 spec
-bit, leading to IOMMU faults, failure to read
from the queue or data corruption.
This patch restricts the coherent DMA mask for legacy PCI virtio devices
to 44 bits, which matches the specification.
Cc: Andy Lutomirski
Cc: Michael S. Tsirkin
Cc: Benjamin Serebrin
Signed-off-by: Will Deacon
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
-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
Cc: Michael S. Tsirkin
Cc: Benjamin Serebrin
Signed-off-by: Will Deacon
---
drivers
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.
> >
-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
Cc: Michael S. Tsirkin
Signed-off-by: Will Deacon
---
drivers/virtio
On Tue, Jan 26, 2016 at 11:58:20AM -0800, Paul E. McKenney wrote:
> On Tue, Jan 26, 2016 at 12:16:09PM +0000, 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:
> > >
On Tue, Jan 26, 2016 at 03:37:33PM -0800, Paul E. McKenney wrote:
> On Tue, Jan 26, 2016 at 12:10:10PM +0000, Will Deacon wrote:
> > On Mon, Jan 25, 2016 at 05:06:46PM -0800, Paul E. McKenney wrote:
> > > PPC WRCnf+addrs
> > > ""
> > > {
> > >
ocumentation/memory-barriers.txt | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
Acked-by: Will Deacon
Will
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote:
> On Mon, Jan 25, 2016 at 04:42:43PM +0000, 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
On Mon, Jan 25, 2016 at 05:06:46PM -0800, Paul E. McKenney wrote:
> On Mon, Jan 25, 2016 at 02:41:34PM +0000, 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:
>
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 ?
>
> ---
> Documentati
ity:
> 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.
>
> Reported-by: Peter Zijlstra
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
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
>
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 de
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 doesn
On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote:
> On 01/13/2016 02:45 AM, Will Deacon wrote:
> >>
> >I don't think the address dependency is enough on its own. By that
> >reasoning, the following variant (WRC+addr+addr) would work too:
> >
&g
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 light
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
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
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: Alexan
have kept it because clearing the flag
> cannot be harmful.
>
> [1] http://lkml.kernel.org/r/87h9k4kzcv.fsf%40yhuang-dev.intel.com
>
> drivers/virtio/virtio_ring.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks for cleaning this up:
Acked-by: Will Deacon
Wil
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..5d1d0
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.
>
>
On Tue, Oct 23, 2012 at 12:55:57AM +0100, Rusty Russell wrote:
> Will Deacon writes:
>
> > Some virtio device drivers (9p) need to translate high virtual addresses
> > to physical addresses, which are inserted into the virtqueue for
> > processing by userspace.
> &
scatterlist with junk.
This patch uses kmap_to_page when populating the page array for a kernel
buffer.
Cc: Rusty Russell
Cc: Sasha Levin
Signed-off-by: Will Deacon
---
net/9p/trans_virtio.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/9p/trans_virtio.c b/net/9p
Levin
Signed-off-by: Will Deacon
---
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 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio
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
Hi Rusty,
On Thu, Oct 18, 2012 at 03:19:06AM +0100, Rusty Russell wrote:
> Will Deacon writes:
> > When using a virtio transport, the 9p net device allocates pages to back
> > the descriptors inserted into the virtqueue. These allocations may be
> > performed from atom
101 - 189 of 189 matches
Mail list logo
