On Tue, Aug 15, 2017 at 02:07:51PM +0200, Igor Mammedov wrote:
> On Tue, 15 Aug 2017 12:15:48 +0100
> Anthony PERARD wrote:
>
> > To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> > set, but this was done only when ACPI tables are built which is not
> > needed for a Xen g
On Thu, Aug 17, 2017 at 05:23:46PM +0100, Anthony PERARD wrote:
> This means that the function will be call and the property
> acpi-pcihp-bsel will be set even if ACPI build is disable.
>
> To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> set, but this was done only when
On Fri, Aug 18, 2017 at 04:19:57PM +0200, Igor Mammedov wrote:
> > > >
> > > > Clean it up after 2.10.
> > > >
> >
> > So is the v2 good enough or do I need to resend it?
> Do you really need it in 2.10?
> it's only 2 days left till release so unless it's blocker
> I'd wait till after release
On Fri, Aug 18, 2017 at 05:00:18PM +0100, Anthony PERARD wrote:
> > > > >
> > > > > Clean it up after 2.10.
> > > > >
> > >
> > > So is the v2 good enough or do I need to resend it?
> > Do you really need it in 2.10?
> > it's only 2 days left till release so unless it's blocker
> > I'd wait ti
On Fri, Oct 13, 2017 at 03:46:39PM -0700, Stefano Stabellini wrote:
> On Fri, 13 Oct 2017, Jan Beulich wrote:
> > >>> On 13.10.17 at 13:13, wrote:
> > > To Jan, Andrew, Stefano and Anthony,
> > >
> > > what do you think about allowing QEMU to build the entire guest ACPI
> > > and letting SeaBIOS
On Fri, Oct 13, 2017 at 03:53:26PM +0800, Haozhong Zhang wrote:
> On 10/12/17 17:45 +0200, Paolo Bonzini wrote:
> > On 12/10/2017 14:45, Haozhong Zhang wrote:
> > > Basically, QEMU builds two ROMs for guest, /rom@etc/acpi/tables and
> > > /rom@etc/table-loader. The former is unstructured to guest,
From: Eduardo Habkost
xen-pt doesn't set the is_express field, but is supposed to be
able to handle PCI Express devices too. Mark it as hybrid.
Suggested-by: Jan Beulich
Signed-off-by: Eduardo Habkost
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/xen/xen
-by: Eduardo Habkost
Reviewed-by: David Gibson
Acked-by: David Gibson
Reviewed-by: Marcel Apfelbaum
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/acpi/piix4.c | 1 +
hw/audio/ac97.c | 4
hw/audio/es1370.c
t; will be done in Xen side and so skip the check in Qemu to avoid blocking
> > Xen creating >255 vcpus.
> > We may make Qemu have knowledge of the vIOMMU device if it's
> > necessary when adding new function.
>
> I was expecting it to go through the PC
On Fri, Aug 11, 2017 at 04:11:37PM +0100, Anthony PERARD wrote:
> To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> set, but this was done only when ACPI tables are built which is not
> needed for a Xen guest. The need for the property starts with commit
> "pc: pcihp: avoid
On Mon, Aug 14, 2017 at 03:55:50PM +0100, Anthony PERARD wrote:
> On Fri, Aug 11, 2017 at 08:18:28PM +0300, Michael S. Tsirkin wrote:
> > On Fri, Aug 11, 2017 at 04:11:37PM +0100, Anthony PERARD wrote:
> > > To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to
On Mon, Aug 14, 2017 at 05:45:02PM +0100, Anthony PERARD wrote:
> On Mon, Aug 14, 2017 at 06:53:14PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Aug 14, 2017 at 03:55:50PM +0100, Anthony PERARD wrote:
> > > On Fri, Aug 11, 2017 at 08:18:28PM +0300, Michael S. Tsirkin wrote:
>
On Mon, Apr 20, 2015 at 04:32:12PM +0200, Michael S. Tsirkin wrote:
> On Mon, Apr 20, 2015 at 03:08:09PM +0100, Jan Beulich wrote:
> > >>> On 20.04.15 at 15:43, wrote:
> > > On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan Beulich wrote:
> > >> >>>
On Mon, Jun 08, 2015 at 09:09:15AM +0100, Malcolm Crossley wrote:
> On 08/06/15 08:42, Jan Beulich wrote:
> >>>> On 07.06.15 at 08:23, wrote:
> >> On Mon, Apr 20, 2015 at 04:32:12PM +0200, Michael S. Tsirkin wrote:
> >>> On Mon, Apr 20, 2015 at 03:08:09PM
On Mon, Jun 08, 2015 at 08:42:57AM +0100, Jan Beulich wrote:
> >>> On 07.06.15 at 08:23, wrote:
> > On Mon, Apr 20, 2015 at 04:32:12PM +0200, Michael S. Tsirkin wrote:
> >> On Mon, Apr 20, 2015 at 03:08:09PM +0100, Jan Beulich wrote:
> >> > >>> On
On Mon, Jun 08, 2015 at 10:03:18AM +0100, Jan Beulich wrote:
> >>> On 08.06.15 at 10:09, wrote:
> > On 08/06/15 08:42, Jan Beulich wrote:
> >> Not really. All we concluded so far is that _maybe_ the bridge, upon
> >> seeing the UR, generates a Master Abort, rendering the whole thing
> >> fatal. Ot
On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote:
> >>> On 08.06.15 at 11:36, wrote:
> > On Mon, Jun 08, 2015 at 10:03:18AM +0100, Jan Beulich wrote:
> >> >>> On 08.06.15 at 10:09, wrote:
> >> > I believe the correct behaviour is happening but a PCIE completion
> >> > timeout
> >> >
this
> issue only seems to reproduce when this patch set is applied.
>
>
> Michael S. Tsirkin:
> "You need some other API that makes sense, probably PCI specific."
> This is basically patch #2: "Extend device listener interface..."
>
> &
On Tue, Jun 09, 2015 at 09:18:49AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > Sent: 09 June 2015 10:13
> > To: Don Slutz
> > Cc: qemu-de...@nongnu.org; xen-devel@lists.xen.org; Paul Durrant;
>
On Tue, Jun 09, 2015 at 10:58:26AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > Sent: 09 June 2015 11:52
> > To: Paul Durrant
> > Cc: Don Slutz; qemu-de...@nongnu.org; xen-devel@lists.xen.org; Stef
On Tue, Jun 09, 2015 at 02:14:29PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > Sent: 09 June 2015 13:30
> > To: Paul Durrant
> > Cc: Don Slutz; qemu-de...@nongnu.org; xen-devel@lists.xen.org; Stef
On Wed, Jun 10, 2015 at 08:00:55AM +0100, Jan Beulich wrote:
> >>> On 08.06.15 at 13:28, wrote:
> > On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote:
> >> while function 0 has
> >>
> >> 0x10: Base Address Register 0 = 0xca23000c (Memory space, 64-bit access,
> >> prefetchable)
> >> 0
On Wed, Jun 10, 2015 at 08:08:37AM +0100, Jan Beulich wrote:
> >>> On 08.06.15 at 11:30, wrote:
> > What happens if you disable SERR# in the command register
> > of 83:00.1?
>
> We've just been told that with SERR not enabled in any of the
> sibling endpoints the NMI still occurs. Not really surp
On Wed, Jun 10, 2015 at 01:06:27PM +0100, Jan Beulich wrote:
> >>> On 10.06.15 at 13:43, wrote:
> > On Wed, Jun 10, 2015 at 08:00:55AM +0100, Jan Beulich wrote:
> >> >>> On 08.06.15 at 13:28, wrote:
> >> > On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote:
> >> >> while function 0 has
>
Rename controller flag to make it clearer what it means.
Add some documentation as well.
Signed-off-by: Michael S. Tsirkin
---
include/hw/pci/msi.h | 2 +-
hw/i386/kvm/apic.c | 2 +-
hw/i386/xen/xen_apic.c | 2 +-
hw/intc/apic.c | 2 +-
hw/intc
Rename controller flag to make it clearer what it means.
Add some documentation as well.
Signed-off-by: Michael S. Tsirkin
---
include/hw/pci/msi.h | 2 +-
hw/i386/kvm/apic.c | 2 +-
hw/i386/xen/xen_apic.c | 2 +-
hw/intc/apic.c | 2 +-
hw/intc
Stefano Stabellini
Tested-by: Michael S. Tsirkin
> ---
> include/hw/xen/xen_common.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 38f29fb..ed5fd3e 100644
> --- a/include/hw/
On Wed, May 13, 2015 at 06:29:46PM +0100, Stefano Stabellini wrote:
> Do not emulate a floppy drive if no drives are supposed to be present.
>
> This fixes the behavior of -nodefaults, that should remove the floppy
> drive (see docs/qdev-device-use.txt:Default Devices), but actually
> doesn't.
>
On Thu, May 14, 2015 at 06:38:24AM +0200, Stefan Weil wrote:
> Am 13.05.2015 um 20:15 schrieb Stefano Stabellini:
> >On Wed, 13 May 2015, Daniel P. Berrange wrote:
> >>On Wed, May 13, 2015 at 06:29:46PM +0100, Stefano Stabellini wrote:
> >>>Do not emulate a floppy drive if no drives are supposed to
On Thu, May 14, 2015 at 12:18:26PM +0100, Daniel P. Berrange wrote:
> On Thu, May 14, 2015 at 12:12:52PM +0100, Stefano Stabellini wrote:
> > On Wed, 13 May 2015, John Snow wrote:
> > > On 05/13/2015 02:15 PM, Stefano Stabellini wrote:
> > > > On Wed, 13 May 2015, Daniel P. Berrange wrote:
> > > >>
On Thu, May 14, 2015 at 12:12:52PM +0100, Stefano Stabellini wrote:
> I would be OK with a new property too, as we could set it from
> libxl or libvirt. Anybody would be happy to pick this one up or should I
> do it?
Pls go ahead, I can merge it in the pc tree.
--
MST
__
On Thu, May 14, 2015 at 01:54:22PM +0200, Paolo Bonzini wrote:
>
>
> On 14/05/2015 13:47, Michael S. Tsirkin wrote:
> > > I would be OK with a new property too, as we could set it from
> > > libxl or libvirt. Anybody would be happy to pick this one up or should I
On Thu, May 14, 2015 at 03:25:39PM +0200, Sander Eikelenboom wrote:
>
> Thursday, May 14, 2015, 2:53:17 PM, you wrote:
>
>
>
> > On 14/05/2015 14:45, Markus Armbruster wrote:
> >> Paolo Bonzini writes:
> >>
> >>> On 14/05/2015 14:02, Markus Armbruster wrote:
> It should certainly be of
On Thu, May 14, 2015 at 02:02:04PM +0200, Markus Armbruster wrote:
> Correct.
>
> Here's how I think it should be done:
>
> * Create a machine option to control the FDC
>
> This is a machine-specific option. It should only exist for machine
> types that have an optional FDC.
>
> Default
n actually see whenever max-ram-below-4g
is zero or not.
Reported-by: Anthony PERARD
Tested-by: Anthony PERARD
Signed-off-by: Gerd Hoffmann
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/i386/pc.c | 2 +-
hw/i386/pc_p
n actually see whenever max-ram-below-4g
is zero or not.
Reported-by: Anthony PERARD
Tested-by: Anthony PERARD
Signed-off-by: Gerd Hoffmann
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
hw/i386/pc.c | 2 +-
hw/i386/pc_p
On Fri, Jan 29, 2016 at 10:34:59AM +, David Vrabel wrote:
> On 29/01/16 02:31, Andy Lutomirski wrote:
> > Signed-off-by: Andy Lutomirski
> > ---
> > drivers/virtio/virtio_ring.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/virtio/virtio_ring.c b/driver
On Thu, Jan 28, 2016 at 06:31:13PM -0800, Andy Lutomirski wrote:
> This switches virtio to use the DMA API on Xen and if requested by
> module option.
>
> This fixes virtio on Xen, and it should break anything because it's
> off by default on everything except Xen PV on x86.
>
> To the Xen people
On Sun, Jan 31, 2016 at 12:13:58PM -0800, Andy Lutomirski wrote:
> On Sun, Jan 31, 2016 at 12:09 PM, Michael S. Tsirkin wrote:
> > On Fri, Jan 29, 2016 at 10:34:59AM +, David Vrabel wrote:
> >> On 29/01/16 02:31, Andy Lutomirski wrote:
> >> >
On Mon, Feb 01, 2016 at 11:22:03AM +, David Woodhouse wrote:
> On Thu, 2016-01-28 at 18:31 -0800, Andy Lutomirski wrote:
> > This is a kludge, but no one has come up with a a better idea yet.
> > We'll introduce DMA API support guarded by vring_use_dma_api().
> > Eventually we may be able to re
On Mon, Feb 01, 2016 at 10:00:56AM -0800, Andy Lutomirski wrote:
> This leaves vring_new_virtqueue alone for compatbility, but it
> adds two new improved APIs:
>
> vring_create_virtqueue: Creates a virtqueue backed by automatically
> allocated coherent memory. (Some day it this could be extended
On Tue, Feb 02, 2016 at 09:46:36PM -0800, Andy Lutomirski wrote:
> virtio_ring currently sends the device (usually a hypervisor)
> physical addresses of its I/O buffers. This is okay when DMA
> addresses and physical addresses are the same thing, but this isn't
> always the case. For example, thi
On Thu, Feb 04, 2016 at 05:05:46PM +, Stefano Stabellini wrote:
> Hi Michael,
>
> do you have any comments on this?
I dislike how it spreads xen specific stuff around,
but I don't have a better idea at the moment, so
I applied this.
> On Wed, 13 Jan 2016, Stefano Stabellini wrote:
> > On Xen
e by ignoring the masking bit for MSI and MSI-X which have
been remapped into pirqs.
Signed-off-by: Stefano Stabellini
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
include/hw/xen/xen.h | 1 +
hw/pci/msi.c | 9 -
hw/pci/msix.c| 12 ++--
e by ignoring the masking bit for MSI and MSI-X which have
been remapped into pirqs.
Signed-off-by: Stefano Stabellini
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
include/hw/xen/xen.h | 1 +
hw/pci/msi.c | 9 -
hw/pci/msix.c| 12 ++--
On Tue, Feb 16, 2016 at 09:48:58PM -0800, Andy Lutomirski wrote:
> On Tue, Feb 2, 2016 at 9:46 PM, Andy Lutomirski wrote:
> > This switches virtio to use the DMA API on Xen and if requested by
> > module option.
>
> Michael, any update on this?
>
> --Andy
I was hoping for an explicit ack from D
On Wed, Dec 02, 2015 at 04:56:21PM +, Stefano Stabellini wrote:
> On Xen MSIs can be remapped into pirqs, which are a type of event
> channels. It's mostly for the benefit of PCI passthrough devices, to
> avoid the overhead of interacting with the emulated lapic.
>
> However remapping interrup
On Wed, Dec 02, 2015 at 05:16:18PM +, Stefano Stabellini wrote:
> On Wed, 2 Dec 2015, Michael S. Tsirkin wrote:
> > On Wed, Dec 02, 2015 at 04:56:21PM +, Stefano Stabellini wrote:
> > > On Xen MSIs can be remapped into pirqs, which are a type of event
> > > ch
On Mon, Dec 14, 2015 at 02:00:05PM +, David Vrabel wrote:
> On 07/12/15 16:19, Stefano Stabellini wrote:
> > Hi all,
> >
> > this patch series introduces support for running Linux on top of Xen
> > inside a virtual machine with virtio devices (nested virt scenario).
> > The problem is that Lin
On Mon, Dec 14, 2015 at 10:27:52AM -0800, Andy Lutomirski wrote:
> On Mon, Dec 14, 2015 at 6:12 AM, Michael S. Tsirkin wrote:
> > On Mon, Dec 14, 2015 at 02:00:05PM +, David Vrabel wrote:
> >> On 07/12/15 16:19, Stefano Stabellini wrote:
> >> > Hi all,
&
On Tue, Dec 15, 2015 at 08:45:32AM -0800, Andy Lutomirski wrote:
> On Tue, Dec 15, 2015 at 4:13 AM, Stefano Stabellini
> wrote:
> > On Mon, 14 Dec 2015, Andy Lutomirski wrote:
> >> On Mon, Dec 14, 2015 at 6:12 AM, Michael S. Tsirkin
> >> wrote:
> >> >
On Thu, Dec 17, 2015 at 03:39:10PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 17, 2015 at 04:33:44PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Dec 17, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote:
> > >
> > > You could of course go fix that instead of mutilatin
On Sun, Dec 20, 2015 at 08:59:44PM +0100, Peter Zijlstra wrote:
> On Sun, Dec 20, 2015 at 05:07:19PM +, Andrew Cooper wrote:
> >
> > Very much +1 for fixing this.
> >
> > Those names would be fine, but they do add yet another set of options in
> > an already-complicated area.
> >
> > An alte
uses it as such by mistake.
Signed-off-by: Michael S. Tsirkin
---
Note: I'm guessing an ack from arch maintainers will be needed, but
I'm working on a bigger cleanup moving a bunch of duplicated code
into asm-generic/barrier.h which depends on this, so not Cc'ing
widely yet.
On Mon, Dec 21, 2015 at 10:47:49AM +, David Vrabel wrote:
> On 20/12/15 09:25, Michael S. Tsirkin wrote:
> >
> > I noticed that drivers/xen/xenbus/xenbus_comms.c uses
> > full memory barriers to communicate with the other side.
> > For example:
> >
>
this exact purpose.
Signed-off-by: Michael S. Tsirkin
---
This is straight-forward, but untested.
I can either merge this patchset through my tree if this is
acked, or defer this and merge the patchset first,
and xen bits through xen tree afterwards.
Pls let me know.
drivers/xen/xenbus
exact purpose.
Signed-off-by: Michael S. Tsirkin
---
include/xen/interface/io/ring.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h
index 7dc685b..46dfc65 100644
--- a/include/xen/interface/io
asm-generic/barrier.h defines a nop() macro.
To be able to use this header on ia64, we shouldn't
call local functions/variables nop().
There's one instance where this breaks on ia64:
rename the function to iosapic_nop to avoid the conflict.
Signed-off-by: Michael S. Tsirkin
Acked-by:
Allow architectures to override smp_store_release
and smp_load_acquire by guarding the defines
in asm-generic/barrier.h with ifndef directives.
This is in preparation to reusing asm-generic/barrier.h
on architectures which have their own definition
of these macros.
Signed-off-by: Michael S
On ia64 smp_rmb, smp_wmb, read_barrier_depends, smp_read_barrier_depends
and smp_store_mb() match the asm-generic variants exactly. Drop the
local definitions and pull in asm-generic/barrier.h instead.
This is in preparation to refactoring this code area.
Signed-off-by: Michael S. Tsirkin
Acked
e smp_store_mb,
the fix is trivial although my code is not optimal:
if anyone cares, pls send me a patch to apply on top.
I didn't build this architecture, but intel's 0-day
infrastructure builds it.
tested on x86
Davidlohr Bueso (1):
lcoking/barriers, arch: Use smp barrier
From: Davidlohr Bueso
With commit b92b8b35a2e ("locking/arch: Rename set_mb() to smp_store_mb()")
it was made clear that the context of this call (and thus set_mb)
is strictly for CPU ordering, as opposed to IO. As such all archs
should use the smp variant of mb(), respecting the semantics and
sa
generic version, drop that as well.
This is in preparation to refactoring this code area.
Note: nop() was in processor.h and not in barrier.h as on other
architectures. Nothing seems to depend on it being there though.
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/sparc
-off-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/arm64/include/asm/barrier.h | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
index 9622eb4..91a43f4 100644
--- a/arch/arm64/include/asm
-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/powerpc/include/asm/barrier.h | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/barrier.h
b/arch/powerpc/include/asm/barrier.h
index a7af5fb..980ad0c 100644
--- a/arch/powerpc/include/asm
: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/s390/include/asm/barrier.h | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/s390/include/asm/barrier.h b/arch/s390/include/asm/barrier.h
index 7ffd0b1..c358c31 100644
--- a/arch/s390/include/asm/barrier.h
refactoring this code area.
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/arm/include/asm/barrier.h | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 3ff5642..31152e8
.
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/mips/include/asm/barrier.h | 25 ++---
1 file changed, 2 insertions(+), 23 deletions(-)
diff --git a/arch/mips/include/asm/barrier.h b/arch/mips/include/asm/barrier.h
index 752e0b8..3eac4b9 100644
--- a/arch/mips
This defines __smp_xxx barriers for powerpc
for use by virtualization.
smp_xxx barriers are removed as they are
defined correctly by asm-generic/barriers.h
This reduces the amount of arch-specific boiler-plate code.
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/powerpc
ones or barrier() depending on
SMP, identically for all architectures.
We keep ifndef guards around them for now - once/if all
architectures are converted to use the generic
code, we'll be able to remove these.
Suggested-by: Peter Zijlstra
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd Ber
This defines __smp_xxx barriers for arm64,
for use by virtualization.
smp_xxx barriers are removed as they are
defined correctly by asm-generic/barriers.h
Note: arm64 does not support !SMP config,
so smp_xxx and __smp_xxx are always equivalent.
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd
.
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/metag/include/asm/barrier.h | 25 ++---
1 file changed, 2 insertions(+), 23 deletions(-)
diff --git a/arch/metag/include/asm/barrier.h b/arch/metag/include/asm/barrier.h
index 172b7e5..b5b778b 100644
--- a/arch
As on most architectures, on x86 read_barrier_depends and
smp_read_barrier_depends are empty. Drop the local definitions and pull
the generic ones from asm-generic/barrier.h instead: they are identical.
This is in preparation to refactoring this code area.
Signed-off-by: Michael S. Tsirkin
On x86/um CONFIG_SMP is never defined. As a result, several macros
match the asm-generic variant exactly. Drop the local definitions and
pull in asm-generic/barrier.h instead.
This is in preparation to refactoring this code area.
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
This defines __smp_xxx barriers for arm,
for use by virtualization.
smp_xxx barriers are removed as they are
defined correctly by asm-generic/barriers.h
This reduces the amount of arch-specific boiler-plate code.
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/arm/include
This defines __smp_xxx barriers for blackfin,
for use by virtualization.
smp_xxx barriers are removed as they are
defined correctly by asm-generic/barriers.h
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/blackfin/include/asm/barrier.h | 4 ++--
1 file changed, 2
This defines __smp_xxx barriers for ia64,
for use by virtualization.
smp_xxx barriers are removed as they are
defined correctly by asm-generic/barriers.h
This reduces the amount of arch-specific boiler-plate code.
Signed-off-by: Michael S. Tsirkin
Acked-by: Tony Luck
Acked-by: Arnd Bergmann
This defines __smp_xxx barriers for tile,
for use by virtualization.
Some smp_xxx barriers are removed as they are
defined correctly by asm-generic/barriers.h
Note: for 32 bit, keep smp_mb__after_atomic around since it's faster
than the generic implementation.
Signed-off-by: Michael S. Ts
between
SMP and !SMP. For this reason, this patch introduces a wrapper
metag_fence() that doesn't depend on CONFIG_SMP.
fence() is then defined using that, depending on CONFIG_SMP.
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/metag/include/asm/barrier.h
sh variant of smp_store_mb() calls xchg() on !SMP which is stronger than
implied by both the name and the documentation.
define __smp_store_mb instead: code in asm-generic/barrier.h
will then define smp_store_mb correctly depending on
CONFIG_SMP.
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd
This defines __smp_xxx barriers for sparc,
for use by virtualization.
smp_xxx barriers are removed as they are
defined correctly by asm-generic/barriers.h
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/sparc/include/asm/barrier_64.h | 8
1 file changed, 4
/barriers.h) and smp_mb__before_llsc (for use elsewhere on this
architecture).
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/mips/include/asm/barrier.h | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/arch/mips/include/asm/barrier.h
This defines __smp_xxx barriers for s390,
for use by virtualization.
Some smp_xxx barriers are removed as they are
defined correctly by asm-generic/barriers.h
Note: smp_mb, smp_rmb and smp_wmb are defined as full barriers
unconditionally on this architecture.
Signed-off-by: Michael S. Tsirkin
-by: David Miller
Signed-off-by: Michael S. Tsirkin
---
include/asm-generic/barrier.h | 11 +++
Documentation/memory-barriers.txt | 28 +++-
2 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/include/asm-generic/barrier.h b/include/asm-generic
!SMP.
We switch to __smp_XXX barriers in the next patch.
Cc: Peter Zijlstra
Cc: Alexander Duyck
Signed-off-by: Michael S. Tsirkin
---
include/linux/virtio_ring.h | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/include/linux/virtio_ring.h b/include
-by: Michael S. Tsirkin
---
include/linux/virtio_ring.h | 25 -
1 file changed, 4 insertions(+), 21 deletions(-)
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
index 67e06fe..f3fa55b 100644
--- a/include/linux/virtio_ring.h
+++ b/include/linux
This defines __smp_xxx barriers for x86,
for use by virtualization.
smp_xxx barriers are removed as they are
defined correctly by asm-generic/barriers.h
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/x86/include/asm/barrier.h | 31 ---
1 file
This defines __smp_xxx barriers for xtensa,
for use by virtualization.
smp_xxx barriers are removed as they are
defined correctly by asm-generic/barriers.h
Signed-off-by: Michael S. Tsirkin
Acked-by: Arnd Bergmann
---
arch/xtensa/include/asm/barrier.h | 4 ++--
1 file changed, 2 insertions
: Michael S. Tsirkin
---
arch/sh/include/asm/barrier.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/sh/include/asm/barrier.h b/arch/sh/include/asm/barrier.h
index f887c64..0cc5735 100644
--- a/arch/sh/include/asm/barrier.h
+++ b/arch/sh/include/asm/barrier.h
r pointers.
Signed-off-by: Michael S. Tsirkin
---
include/linux/virtio_ring.h | 12
drivers/virtio/virtio_ring.c | 15 +--
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
index f3fa55b..3a74d91 10
exact purpose.
Signed-off-by: Michael S. Tsirkin
---
drivers/xen/xenbus/xenbus_comms.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_comms.c
b/drivers/xen/xenbus/xenbus_comms.c
index fdb0f33..ecdecce 100644
--- a/drivers/xen/xenbus
exact purpose.
Signed-off-by: Michael S. Tsirkin
---
include/xen/interface/io/ring.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h
index 7dc685b..21f4fbd 100644
--- a/include/xen/interface/io
On Fri, Jan 01, 2016 at 11:39:40AM +0200, Michael S. Tsirkin wrote:
> virtio ring uses smp_wmb on SMP and wmb on !SMP,
> the reason for the later being that it might be
> talking to another kernel on the same SMP machine.
>
> This is exactly what __smp_XXX barriers do,
>
On Fri, Jan 01, 2016 at 08:23:46PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 12/31/2015 10:09 PM, Michael S. Tsirkin wrote:
>
> >We need a full barrier after writing out event index, using
> >virt_store_mb there seems better than open-coding. As usual, we need a
&
On Sat, Jan 02, 2016 at 11:24:38AM +, Russell King - ARM Linux wrote:
> On Thu, Dec 31, 2015 at 09:07:59PM +0200, Michael S. Tsirkin wrote:
> > This defines __smp_xxx barriers for arm,
> > for use by virtualization.
> >
> > smp_xxx barriers are removed as they are
&
As part of memory barrier cleanup, this patchset
extends checkpatch to make it easier to stop
incorrect memory barrier usage.
This applies on top of my series
arch: barrier cleanup + barriers for virt
and will be included in the next version of the series.
Michael S. Tsirkin (3
a checkpatch test so it will trigger a warning.
Reported-by: Russell King
Signed-off-by: Michael S. Tsirkin
---
scripts/checkpatch.pl | 11 +++
1 file changed, 11 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0245bbe..e3f9ad9 100755
--- a/scripts/checkpa
SMP-only barriers were missing in checkpatch.pl
Refactor code slightly to make adding more variants easier.
Signed-off-by: Michael S. Tsirkin
---
scripts/checkpatch.pl | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
Add virt_ barriers to list of barriers to check for
presence of a comment.
Signed-off-by: Michael S. Tsirkin
---
scripts/checkpatch.pl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e3f9ad9..5fb6ef7 100755
--- a/scripts
/barrier.h here to make sure the file is self-contained.
Suggested-by: David Vrabel
Signed-off-by: Michael S. Tsirkin
---
This is on top of my series:
arch: barrier cleanup + barriers for virt
and will be included in v3 of the series.
drivers/xen/events/events_fifo.c | 3 ++-
1 file changed
1 - 100 of 203 matches
Mail list logo
