Re: [Xen-devel] [RFC][PATCH 2/2] xen:i386:pc_piix: create isa bridge specific to IGD passthrough

On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote: On 2014/11/5 22:09, Michael S. Tsirkin wrote: On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote: Currently IGD drivers always need to access PCH by 1f.0, and PCH vendor/device id is used to identify the card. Signed-off

Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 2/2] xen:i386:pc_piix: create isa bridge specific to IGD passthrough

On Mon, Nov 17, 2014 at 07:18:17PM +0800, Chen, Tiejun wrote: On 2014/11/17 18:13, Michael S. Tsirkin wrote: On Mon, Nov 17, 2014 at 05:42:12PM +0800, Chen, Tiejun wrote: On 2014/11/17 17:25, Michael S. Tsirkin wrote: On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote: On 2014/11/17

Re: [Xen-devel] [v5][PATCH 0/4] xen: introduce new machine for IGD passthrough

On Tue, Aug 12, 2014 at 05:49:13PM +0800, Tiejun Chen wrote: v5: * Simplify to make sure its really inherited from the standard one in patch #3 * Then drop the original patch #3 I carried i440fx: make types configurable at run-time pc_init1: pass parameters just with types

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

On Wed, Apr 01, 2015 at 10:41:12AM +0100, Andrew Cooper wrote: On 01/04/15 10:20, Stefano Stabellini wrote: CC'ing the author of the patch and xen-devel. FYI I think that Jan is going to be on vacation for a couple of weeks. On Wed, 1 Apr 2015, Michael S. Tsirkin wrote: On Tue, Mar 31

Re: [Xen-devel] [PATCH v1 05/47] pci: add pci_iomap_wc() variants

On Mon, Mar 23, 2015 at 12:20:47PM -0500, Bjorn Helgaas wrote: pci_iomap_range() already makes a cacheable mapping if IORESOURCE_CACHEABLE; I'm guessing that you would like it to automatically use WC if the BAR if IORESOURCE_PREFETCH, e.g., if (flags IORESOURCE_CACHEABLE) return

Re: [Xen-devel] [PATCH v1 05/47] pci: add pci_iomap_wc() variants

On Tue, Apr 21, 2015 at 07:52:49PM +0200, Luis R. Rodriguez wrote: On Thu, Mar 26, 2015 at 04:00:54AM +0100, Luis R. Rodriguez wrote: On Mon, Mar 23, 2015 at 12:20:47PM -0500, Bjorn Helgaas wrote: Hi Luis, This seems OK to me, Great. but I'm curious about a few things.

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan Beulich wrote: On 13.04.15 at 14:47, m...@redhat.com wrote: On Mon, Apr 13, 2015 at 01:40:59PM +0100, Jan Beulich wrote: Quite possible. Looking at the ITP log we were provided, the UR severity bit is clear (non-fatal), yet the error got

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

On Mon, Apr 20, 2015 at 03:08:09PM +0100, Jan Beulich wrote: On 20.04.15 at 15:43, m...@redhat.com wrote: On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan Beulich wrote: On 13.04.15 at 14:47, m...@redhat.com wrote: Can you check device capabilities register, offset 0x4 within pci express

Re: [Xen-devel] [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

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 must be

Re: [Xen-devel] [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

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 pbonz...@redhat.com writes: On 14/05/2015 14:02, Markus Armbruster wrote: It should certainly be off

Re: [Xen-devel] [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

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 do it? Pls go ahead, I can merge

Re: [Xen-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

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.

Re: [Xen-devel] [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

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 Wed, May

Re: [Xen-devel] [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

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

Re: [Xen-devel] [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

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 be

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

On Mon, Apr 13, 2015 at 12:34:34PM +0100, Jan Beulich wrote: On 13.04.15 at 13:19, m...@redhat.com wrote: Yes Linux can't fix firmware 1st mode, but PCI express spec says what firmware should do in this case: IMPLEMENTATION NOTE Software UR Reporting Compatibility with 1.0a Devices

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

is going to be on vacation for a couple of weeks. On Wed, 1 Apr 2015, Michael S. Tsirkin wrote: On Tue, Mar 31, 2015 at 03:18:03PM +0100, Stefano Stabellini wrote: From: Jan Beulich jbeul...@suse.com Otherwise the guest can abuse that control to cause e.g. PCIe Unsupported Request

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

On Mon, Apr 13, 2015 at 01:40:59PM +0100, Jan Beulich wrote: On 13.04.15 at 13:47, m...@redhat.com wrote: On Mon, Apr 13, 2015 at 12:34:34PM +0100, Jan Beulich wrote: On 13.04.15 at 13:19, m...@redhat.com wrote: Yes Linux can't fix firmware 1st mode, but PCI express spec says what

Re: [Xen-devel] [PATCH v2 0/4] Fix device listener interface for PCI to PCI bridges

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... This is relying on undocumented assumptions and how specific firmware works. There's nothing

Re: [Xen-devel] [PATCH v2 0/4] Fix device listener interface for PCI to PCI bridges

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; Stefano Stabellini Subject: Re: [PATCH

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

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, m...@redhat.com 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

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

On Mon, Jun 08, 2015 at 10:03:18AM +0100, Jan Beulich wrote: On 08.06.15 at 10:09, malcolm.cross...@citrix.com 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

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

On Mon, Jun 08, 2015 at 08:42:57AM +0100, Jan Beulich wrote: On 07.06.15 at 08:23, m...@redhat.com 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, m...@redhat.com wrote

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote: On 08.06.15 at 11:36, m...@redhat.com wrote: On Mon, Jun 08, 2015 at 10:03:18AM +0100, Jan Beulich wrote: On 08.06.15 at 10:09, malcolm.cross...@citrix.com wrote: I believe the correct behaviour is happening but a PCIE

Re: [Xen-devel] [PATCH v2 0/4] Fix device listener interface for PCI to PCI bridges

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; Stefano Stabellini Subject: Re: [PATCH

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

On Wed, Jun 10, 2015 at 08:00:55AM +0100, Jan Beulich wrote: On 08.06.15 at 13:28, m...@redhat.com 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) 0x18:

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

On Wed, Jun 10, 2015 at 08:08:37AM +0100, Jan Beulich wrote: On 08.06.15 at 11:30, m...@redhat.com 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

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

On Wed, Jun 10, 2015 at 01:06:27PM +0100, Jan Beulich wrote: On 10.06.15 at 13:43, m...@redhat.com wrote: On Wed, Jun 10, 2015 at 08:00:55AM +0100, Jan Beulich wrote: On 08.06.15 at 13:28, m...@redhat.com wrote: On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote: while

Re: [Xen-devel] [PATCH v2 0/4] Fix device listener interface for PCI to PCI bridges

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; Stefano Stabellini Subject: Re: [PATCH

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

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, m...@redhat.com wrote: On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan Beulich wrote: On 13.04.15 at 14:47, m...@redhat.com wrote: Can

Re: [Xen-devel] [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API

On Tue, Jul 28, 2015 at 02:46:20PM +0200, Paolo Bonzini wrote: On 28/07/2015 12:12, Benjamin Herrenschmidt wrote: That is an experimental feature (it's x-iommu), so it can change. The plan was: - for PPC, virtio never honors IOMMU - for non-PPC, either have virtio

Re: [Xen-devel] [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API

On Mon, Jul 27, 2015 at 06:08:59PM -0700, Andy Lutomirski wrote: On Mon, Sep 1, 2014 at 10:39 AM, Andy Lutomirski l...@amacapital.net wrote: This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This

Re: [Xen-devel] [PATCH] Fix the compatibility typedef of ioservid_t to match the Xen headers

: Stefano Stabellini stefano.stabell...@eu.citrix.com Tested-by: Michael S. Tsirkin m...@redhat.com --- 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

[Xen-devel] [PULL 2/7] pc: Remove redundant arguments from xen_hvm_init()

From: Eduardo Habkost <ehabk...@redhat.com> Remove arguments that can be found in PCMachineState. Signed-off-by: Eduardo Habkost <ehabk...@redhat.com> Reviewed-by: Michael S. Tsirkin <m...@redhat.com> Signed-off-by: Michael S. Tsirkin <m...@redhat.com> --- include/hw

Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

On Thu, Sep 10, 2015 at 11:29:18AM +0100, Stefano Stabellini wrote: > CC Michael > > On Thu, 10 Sep 2015, Stefano Stabellini wrote: > > On Thu, 10 Sep 2015, Chen, Tiejun wrote: > > > > xen-host-pci-device.c is only compiled if CONFIG_XEN_PCI_PASSTHROUGH > > > > was set by configure. That won't be

Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

On Thu, Sep 10, 2015 at 12:26:21PM +0100, Stefano Stabellini wrote: > On Thu, 10 Sep 2015, Michael S. Tsirkin wrote: > > On Thu, Sep 10, 2015 at 11:29:18AM +0100, Stefano Stabellini wrote: > > > CC Michael > > > > > > On Thu, 10 Sep 2015, Stefano Stabellin

Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

On Thu, Sep 10, 2015 at 01:00:35PM +0100, Stefano Stabellini wrote: > On Thu, 10 Sep 2015, Michael S. Tsirkin wrote: > > On Thu, Sep 10, 2015 at 12:26:21PM +0100, Stefano Stabellini wrote: > > > On Thu, 10 Sep 2015, Michael S. Tsirkin wrote: > > > > On Thu, Se

Re: [Xen-devel] [PATCH] fix MSI injection on Xen

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

Re: [Xen-devel] [PATCH] fix MSI injection on Xen

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

Re: [Xen-devel] [PATCH RFC 0/3] Xen on Virtio

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

Re: [Xen-devel] [PATCH RFC 0/3] Xen on Virtio

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 <m...@redhat.com> wrote: > > On Mon, Dec 14, 2015 at 02:00:05PM +, David Vrabel wrote: > >> On 07/12/15 16:19, Stefano Stabell

Re: [Xen-devel] [PATCH v2 06/32] s390: reuse asm-generic/barrier.h

On Mon, Jan 04, 2016 at 04:03:39PM +0100, Martin Schwidefsky wrote: > On Mon, 4 Jan 2016 14:20:42 +0100 > Peter Zijlstra <pet...@infradead.org> wrote: > > > On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote: > > > On s390 read_barrier_dep

Re: [Xen-devel] [PATCH 3/3] checkpatch: add virt barriers

On Mon, Jan 04, 2016 at 08:47:53AM -0800, Joe Perches wrote: > On Mon, 2016-01-04 at 13:37 +0200, Michael S. Tsirkin wrote: > > Add virt_ barriers to list of barriers to check for > > presence of a comment. > > Are these virt_ barriers used anywhere? > > I see som

Re: [Xen-devel] [PATCH v2 17/32] arm: define __smp_xxx

On Mon, Jan 04, 2016 at 02:54:20PM +0100, Peter Zijlstra wrote: > On Mon, Jan 04, 2016 at 02:36:58PM +0100, Peter Zijlstra wrote: > > On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote: > > > On Sat, Jan 02, 2016 at 11:24:38AM +, Russell King - ARM Linux wrot

Re: [Xen-devel] [PATCH v2 22/32] s390: define __smp_xxx

On Mon, Jan 04, 2016 at 02:45:25PM +0100, Peter Zijlstra wrote: > On Thu, Dec 31, 2015 at 09:08:38PM +0200, Michael S. Tsirkin wrote: > > This defines __smp_xxx barriers for s390, > > for use by virtualization. > > > > Some smp_xxx barriers are removed as they are &

Re: [Xen-devel] [PATCH v2 17/32] arm: define __smp_xxx

On Mon, Jan 04, 2016 at 02:36:58PM +0100, Peter Zijlstra wrote: > On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote: > > On Sat, Jan 02, 2016 at 11:24:38AM +, Russell King - ARM Linux wrote: > > > > My only concern is that it gives people an a

Re: [Xen-devel] [PATCH v2 06/32] s390: reuse asm-generic/barrier.h

On Mon, Jan 04, 2016 at 02:20:42PM +0100, Peter Zijlstra wrote: > On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote: > > On s390 read_barrier_depends, smp_read_barrier_depends > > smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the > >

Re: [Xen-devel] [PATCH 1/3] checkpatch.pl: add missing memory barriers

On Mon, Jan 04, 2016 at 08:07:40AM -0800, Joe Perches wrote: > On Mon, 2016-01-04 at 13:36 +0200, Michael S. Tsirkin wrote: > > SMP-only barriers were missing in checkpatch.pl > > > > Refactor code slightly to make adding more variants easier. > > > > Sig

[Xen-devel] [PATCH 0/3] checkpatch: handling of memory barriers

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

[Xen-devel] [PATCH 2/3] checkpatch: check for __smp outside barrier.h

ch test so it will trigger a warning. Reported-by: Russell King <li...@arm.linux.org.uk> Signed-off-by: Michael S. Tsirkin <m...@redhat.com> --- scripts/checkpatch.pl | 11 +++ 1 file changed, 11 insertions(+) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 0

[Xen-devel] [PATCH 1/3] checkpatch.pl: add missing memory barriers

SMP-only barriers were missing in checkpatch.pl Refactor code slightly to make adding more variants easier. Signed-off-by: Michael S. Tsirkin <m...@redhat.com> --- scripts/checkpatch.pl | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/scripts/checkpatch.pl b/s

[Xen-devel] [PATCH 3/3] checkpatch: add virt barriers

Add virt_ barriers to list of barriers to check for presence of a comment. Signed-off-by: Michael S. Tsirkin <m...@redhat.com> --- scripts/checkpatch.pl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index e3f9ad9..5

[Xen-devel] [PATCH] xen/events: use virt_xxx barriers

/barrier.h here to make sure the file is self-contained. Suggested-by: David Vrabel <david.vra...@citrix.com> Signed-off-by: Michael S. Tsirkin <m...@redhat.com> --- This is on top of my series: arch: barrier cleanup + barriers for virt and will be included in v3 of the series.

Re: [Xen-devel] [PATCH v2 15/32] powerpc: define __smp_xxx

On Tue, Jan 05, 2016 at 09:36:55AM +0800, Boqun Feng wrote: > Hi Michael, > > On Thu, Dec 31, 2015 at 09:07:42PM +0200, Michael S. Tsirkin wrote: > > This defines __smp_xxx barriers for powerpc > > for use by virtualization. > > > > smp_xxx barriers are removed

Re: [Xen-devel] [PATCH v2 22/32] s390: define __smp_xxx

On Tue, Jan 05, 2016 at 09:13:19AM +0100, Martin Schwidefsky wrote: > On Mon, 4 Jan 2016 22:18:58 +0200 > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > > On Mon, Jan 04, 2016 at 02:45:25PM +0100, Peter Zijlstra wrote: > > > On Thu, Dec 31, 2015 at 09

Re: [Xen-devel] [PATCH v2 32/32] virtio_ring: use virt_store_mb

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

Re: [Xen-devel] [PATCH v2 17/32] arm: define __smp_xxx

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 &

Re: [Xen-devel] [PATCH v2 15/32] powerpc: define __smp_xxx

On Tue, Jan 05, 2016 at 05:53:41PM +0800, Boqun Feng wrote: > On Tue, Jan 05, 2016 at 10:51:17AM +0200, Michael S. Tsirkin wrote: > > On Tue, Jan 05, 2016 at 09:36:55AM +0800, Boqun Feng wrote: > > > Hi Michael, > > > > > > On Thu, Dec 31, 2015 at 09:07:

Re: [Xen-devel] [PATCH v2 22/32] s390: define __smp_xxx

On Tue, Jan 05, 2016 at 04:39:37PM +0100, Christian Borntraeger wrote: > On 01/05/2016 10:30 AM, Michael S. Tsirkin wrote: > > > > > arch/s390/kernel/vdso.c:smp_mb(); > > > > Looking at > > Author: Christian Borntraeger <borntrae...@de.ibm.c

Re: [Xen-devel] [PATCH v2 17/32] arm: define __smp_xxx

On Mon, Jan 04, 2016 at 01:59:34PM +, Russell King - ARM Linux wrote: > On Mon, Jan 04, 2016 at 02:54:20PM +0100, Peter Zijlstra wrote: > > On Mon, Jan 04, 2016 at 02:36:58PM +0100, Peter Zijlstra wrote: > > > On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wro

[Xen-devel] [PATCH v2 31/32] sh: support a 2-byte smp_store_mb

-by: Michael S. Tsirkin <m...@redhat.com> --- 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/i

[Xen-devel] [PATCH v2 32/32] virtio_ring: use virt_store_mb

. Signed-off-by: Michael S. Tsirkin <m...@redhat.com> --- 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..3

[Xen-devel] [PATCH v2 24/32] sparc: define __smp_xxx

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 <m...@redhat.com> Acked-by: Arnd Bergmann <a...@arndb.de> --- arch/sparc/include/asm/barr

[Xen-devel] [PATCH v2 21/32] mips: define __smp_xxx

/barriers.h) and smp_mb__before_llsc (for use elsewhere on this architecture). Signed-off-by: Michael S. Tsirkin <m...@redhat.com> Acked-by: Arnd Bergmann <a...@arndb.de> --- arch/mips/include/asm/barrier.h | 26 ++ 1 file changed, 14 insertions(+), 12 deletions(-)

[Xen-devel] [PATCH v2 22/32] s390: define __smp_xxx

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

[Xen-devel] [PATCH v2 28/32] asm-generic: implement virt_xxx memory barriers

-by: David Miller <da...@davemloft.net> Signed-off-by: Michael S. Tsirkin <m...@redhat.com> --- include/asm-generic/barrier.h | 11 +++ Documentation/memory-barriers.txt | 28 +++- 2 files changed, 34 insertions(+), 5 deletions(-) diff --git a/include

[Xen-devel] [PATCH v2 29/32] Revert "virtio_ring: Update weak barriers to use dma_wmb/rmb"

for !SMP. We switch to __smp_XXX barriers in the next patch. Cc: Peter Zijlstra <pet...@infradead.org> Cc: Alexander Duyck <alexander.du...@gmail.com> Signed-off-by: Michael S. Tsirkin <m...@redhat.com> --- include/linux/virtio_ring.h | 23 +++ 1 file changed, 1

[Xen-devel] [PATCH v2 30/32] virtio_ring: update weak barriers to use __smp_XXX

gt; Cc: Alexander Duyck <alexander.du...@gmail.com> Signed-off-by: Michael S. Tsirkin <m...@redhat.com> --- 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 inde

[Xen-devel] [PATCH v2 27/32] x86: define __smp_xxx

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 <m...@redhat.com> Acked-by: Arnd Bergmann <a...@arndb.de> --- arch/x86/include/asm/ba

[Xen-devel] [PATCH v2 26/32] xtensa: define __smp_xxx

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 <m...@redhat.com> Acked-by: Arnd Bergmann <a...@arndb.de> --- arch/xtensa/include/asm/b

[Xen-devel] [PATCH v2 13/32] x86: reuse asm-generic/barrier.h

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 &l

[Xen-devel] [PATCH v2 12/32] x86/um: reuse asm-generic/barrier.h

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 <m...@redhat.com>

[Xen-devel] [PATCH v2 17/32] arm: define __smp_xxx

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 <m...@redhat.com> Acked-by: Arnd Be

[Xen-devel] [PATCH v2 10/32] metag: reuse asm-generic/barrier.h

. Signed-off-by: Michael S. Tsirkin <m...@redhat.com> Acked-by: Arnd Bergmann <a...@arndb.de> --- 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/bar

[Xen-devel] [PATCH v2 18/32] blackfin: define __smp_xxx

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 <m...@redhat.com> Acked-by: Arnd Bergmann <a...@arndb.de> --- arch/blackfin/include/asm/b

[Xen-devel] [PATCH v2 19/32] ia64: define __smp_xxx

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 <m...@redhat.com> Acked-by: Tony Luck &

[Xen-devel] [PATCH v2 20/32] metag: define __smp_xxx

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 <m...@redhat.com> Acked-by: Arnd Bergmann <a...@arndb.de> --- arch/metag

[Xen-devel] [PATCH v2 23/32] sh: define __smp_xxx, fix smp_store_mb for !SMP

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 &l

[Xen-devel] [PATCH v2 25/32] tile: define __smp_xxx

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

[Xen-devel] [PATCH v2 08/32] arm: reuse asm-generic/barrier.h

to refactoring this code area. Signed-off-by: Michael S. Tsirkin <m...@redhat.com> Acked-by: Arnd Bergmann <a...@arndb.de> --- 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

[Xen-devel] [PATCH v2 11/32] mips: reuse asm-generic/barrier.h

. Signed-off-by: Michael S. Tsirkin <m...@redhat.com> Acked-by: Arnd Bergmann <a...@arndb.de> --- 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 i

[Xen-devel] [PATCH v2 06/32] s390: reuse asm-generic/barrier.h

-by: Michael S. Tsirkin <m...@redhat.com> Acked-by: Arnd Bergmann <a...@arndb.de> --- 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 10064

[Xen-devel] [PATCH v2 01/32] lcoking/barriers, arch: Use smp barriers in smp_store_release()

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

[Xen-devel] [PATCH v2 14/32] asm-generic: add __smp_xxx wrappers

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 <pet...@infradead.org> Signed-off-by: Michael S. Tsir

[Xen-devel] [PATCH v2 16/32] arm64: define __smp_xxx

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 <m...@redhat.

[Xen-devel] [PATCH v2 07/32] sparc: reuse asm-generic/barrier.h

to the 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 <m...@redhat.com> Acked-by: Arnd Be

[Xen-devel] [PATCH v2 09/32] arm64: reuse asm-generic/barrier.h

-off-by: Michael S. Tsirkin <m...@redhat.com> Acked-by: Arnd Bergmann <a...@arndb.de> --- 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..91

[Xen-devel] [PATCH v2 05/32] powerpc: reuse asm-generic/barrier.h

-by: Michael S. Tsirkin <m...@redhat.com> Acked-by: Arnd Bergmann <a...@arndb.de> --- 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..98

[Xen-devel] [PATCH v2 15/32] powerpc: define __smp_xxx

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 <m...@redhat.com> Acked-by: Arnd Be

[Xen-devel] [PATCH v2 33/34] xenbus: use virt_xxx barriers

this exact purpose. Signed-off-by: Michael S. Tsirkin <m...@redhat.com> --- 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/d

[Xen-devel] [PATCH v2 34/34] xen/io: use virt_xxx barriers

this exact purpose. Signed-off-by: Michael S. Tsirkin <m...@redhat.com> --- 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/i

[Xen-devel] [PATCH v2 03/32] ia64: rename nop->iosapic_nop

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 <m...@redhat.

[Xen-devel] [PATCH v2 02/32] asm-generic: guard smp_store_release/load_acquire

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

[Xen-devel] [PATCH v2 04/32] ia64: reuse asm-generic/barrier.h

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 &l

[Xen-devel] [PATCH v2 00/34] arch: barrier cleanup + barriers for virt

y 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 barriers in smp_store_release() Michael S. Tsirkin (33): asm-generic:

Re: [Xen-devel] [PATCH v2 30/32] virtio_ring: update weak barriers to use __smp_xxx

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

Re: [Xen-devel] [PATCH v2 22/32] s390: define __smp_xxx

On Tue, Jan 05, 2016 at 01:08:52PM +0100, Martin Schwidefsky wrote: > On Tue, 5 Jan 2016 11:30:19 +0200 > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > > On Tue, Jan 05, 2016 at 09:13:19AM +0100, Martin Schwidefsky wrote: > > > On Mon, 4 Jan 2016 22:1

Re: [Xen-devel] [PATCH v3 00/11] igd passthrough chipset tweaks

On Tue, Jan 05, 2016 at 12:41:27PM +0100, Gerd Hoffmann wrote: > Hi, > > We have some code in our tree to support pci passthrough of intel > graphics devices (igd) on xen, which requires some chipset tweaks > for (a) the host bridge and (b) the lpc/isa-bridge to meat the > expectations of the

Re: [Xen-devel] [PATCH v2 15/32] powerpc: define __smp_xxx

On Wed, Jan 06, 2016 at 09:51:52AM +0800, Boqun Feng wrote: > On Tue, Jan 05, 2016 at 06:16:48PM +0200, Michael S. Tsirkin wrote: > [snip] > > > > > Another thing is that smp_lwsync() may have a third user(other than > > > > > smp_load_acquire() and smp_store_r

Re: [Xen-devel] [PATCH 3/3] checkpatch: add virt barriers

On Mon, Jan 04, 2016 at 02:11:37PM -0800, Joe Perches wrote: > On Mon, 2016-01-04 at 23:07 +0200, Michael S. Tsirkin wrote: > > On Mon, Jan 04, 2016 at 08:47:53AM -0800, Joe Perches wrote: > > > On Mon, 2016-01-04 at 13:37 +0200, Michael S. Tsirkin wrote: > > > &

  1   2   >