Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure initialization

Did you install some specific agent within VM to utilize vgtbuffer ioctl interface? It’s not a bare metal i915 interface so suppose it shouldn’t be invoked for a default Linux distro environment. Yes we should add check to prevent it from being used within VM. However this error has nothing to

[Xen-devel] [xen-4.3-testing test] 77687: tolerable FAIL - PUSHED

flight 77687 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/77687/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 65650

Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure initialization

Hello. Thanks for answer. About what agent are u talking about? I did not install anything additional, just took vgt kernel and used it for Ubuntu distro. I will look in events, thanks. With the best regards, Oleksii On Mon, 11 Jan 2016, 07:07 Tian, Kevin wrote: > Did

Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure initialization

I don’t know exact agent. As I said, vgtbuffer ioctl interface is used only by new application which wants to composite guest framebuffer. There is no existing application from standard Linux distro using it. So that’s why I’m curious whether you installed something within VM. From: Oleksii

[Xen-devel] [linux-mingo-tip-master test] 77679: regressions - FAIL

flight 77679 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/77679/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 60684

[Xen-devel] [qemu-upstream-4.3-testing test] 77690: regressions - FAIL

flight 77690 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/77690/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 62112

[Xen-devel] [xen-4.4-testing test] 77671: tolerable FAIL - PUSHED

flight 77671 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/77671/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 66458

[Xen-devel] [libvirt test] 77684: tolerable FAIL - PUSHED

flight 77684 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/77684/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt-vhd 9 debian-di-installfail like 77517 Tests which did not succeed, but

Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()

Qemu with the patch can't boot VM with IGD pass-through, I'm checking if it works w/o this patch to eliminate the environment influence. Thanks, -Xudong > -Original Message- > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com] > Sent: Friday, January 8, 2016 7:57 PM >

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

Hi Michael, On Mon, Jan 11, 2016 at 6:31 AM, Michael S. Tsirkin wrote: > 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

[Xen-devel] [PATCH v2 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 --- scripts/checkpatch.pl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index a96adcb..5ca272b

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

Introduction of __smp barriers cleans up a bunch of duplicate code, but it gives people an additional handle onto a "new" set of barriers - just because they're prefixed with __* unfortunately doesn't stop anyone from using it (as happened with other arch stuff before.) Add a checkpatch test so

[Xen-devel] [PATCH v2 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. Changes from v2: catch

[Xen-devel] [PATCH v2 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 --- scripts/checkpatch.pl | 20 +++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git

[Xen-devel] [linux-linus test] 77554: regressions - FAIL

flight 77554 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/77554/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 6 xen-bootfail REGR. vs. 59254

[Xen-devel] [ovmf test] 77570: regressions - FAIL

flight 77570 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/77570/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 65543

[Xen-devel] [qemu-upstream-4.6-testing test] 77562: regressions - trouble: broken/fail/pass

flight 77562 qemu-upstream-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/77562/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 63071

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

On Mon, Jan 04, 2016 at 02:15:50PM -0800, Joe Perches wrote: > On Mon, 2016-01-04 at 22:45 +0200, Michael S. Tsirkin wrote: > > 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

[Xen-devel] [qemu-upstream-4.4-testing test] 77618: regressions - FAIL

flight 77618 qemu-upstream-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/77618/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 62702

[Xen-devel] [PATCH v3 14/41] asm-generic: add __smp_xxx wrappers

On !SMP, most architectures define their barriers as compiler barriers. On SMP, most need an actual barrier. Make it possible to remove the code duplication for !SMP by defining low-level __smp_xxx barriers which do not depend on the value of SMP, then use them from asm-generic conditionally.

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

On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, smp_read_barrier_depends, smp_store_release and smp_load_acquire 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.

[Xen-devel] [PATCH v3 15/41] 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 Acked-by: Arnd Bergmann

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

On metag dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, smp_read_barrier_depends, smp_store_release and smp_load_acquire 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.

[Xen-devel] [PATCH v3 13/41] 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

[Xen-devel] [PATCH v3 26/41] 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 Acked-by: Arnd Bergmann --- arch/xtensa/include/asm/barrier.h | 4 ++--

[Xen-devel] [PATCH v3 24/41] 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 Acked-by: Arnd Bergmann Acked-by: David S. Miller

[Xen-devel] [PATCH v3 27/41] 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 Acked-by: Arnd Bergmann --- arch/x86/include/asm/barrier.h | 31

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

This reverts commit 9e1a27ea42691429e31f158cce6fc61bc79bb2e9. While that commit optimizes !CONFIG_SMP, it mixes up DMA and SMP concepts, making the code hard to figure out. A better way to optimize this is with the new __smp_XXX barriers. As a first step, go back to full rmb/wmb barriers for

[Xen-devel] [PATCH v3 34/41] 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 --- scripts/checkpatch.pl | 20 +++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git

[Xen-devel] [PATCH v3 30/41] virtio_ring: update weak barriers to use virt_xxx

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 virt_xxx barriers do, so switch to these instead of homegrown ifdef hacks. Cc: Peter Zijlstra Cc:

[Xen-devel] [PATCH v3 31/41] sh: support 1 and 2 byte xchg

This completes the xchg implementation for sh architecture. Note: The llsc variant is tricky since this only supports 4 byte atomics, the existing implementation of 1 byte xchg is wrong: we need to do a 4 byte cmpxchg and retry if any bytes changed meanwhile. Write this in C for clarity.

[Xen-devel] [PATCH v3 32/41] sh: move xchg_cmpxchg to a header by itself

Looks like future sh variants will support a 4-byte cas which will be used to implement 1 and 2 byte xchg. This is exactly what we do for llsc now, move the portable part of the code into a separate header so it's easy to reuse. Suggested-by: Rich Felker Signed-off-by: Michael

[Xen-devel] [PATCH v3 33/41] virtio_ring: use virt_store_mb

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 wrapper to account for strong barriers. It's tempting to use this in vhost as well, for that, we'll need a variant of smp_store_mb that works on __user pointers.

[Xen-devel] [PATCH v3 28/41] asm-generic: implement virt_xxx memory barriers

Guests running within virtual machines might be affected by SMP effects even if the guest itself is compiled without SMP support. This is an artifact of interfacing with an SMP host while running an UP kernel. Using mandatory barriers for this use-case would be possible but is often suboptimal.

[Xen-devel] [PATCH v3 25/41] 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 v3 36/41] checkpatch: add virt barriers

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 a96adcb..5ca272b

[Xen-devel] [qemu-upstream-4.5-testing test] 77636: regressions - FAIL

flight 77636 qemu-upstream-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/77636/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 62414

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

On s390 read_barrier_depends, smp_read_barrier_depends smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic 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:

[Xen-devel] [PATCH v3 01/41] 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 v3 03/41] 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

[Xen-devel] [PATCH v3 04/41] 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

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

On powerpc read_barrier_depends, smp_read_barrier_depends smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic 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.

[Xen-devel] [PATCH v3 02/41] 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 v3 08/41] arm: reuse asm-generic/barrier.h

On arm smp_store_mb, read_barrier_depends, smp_read_barrier_depends, smp_store_release, smp_load_acquire, smp_mb__before_atomic and smp_mb__after_atomic match the asm-generic variants exactly. Drop the local definitions and pull in asm-generic/barrier.h instead. This is in preparation to

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

On sparc 64 bit dma_rmb, dma_wmb, smp_store_mb, smp_mb, smp_rmb, smp_wmb, read_barrier_depends and smp_read_barrier_depends match the asm-generic variants exactly. Drop the local definitions and pull in asm-generic/barrier.h instead. nop uses __asm__ __volatile but is otherwise identical to the

Re: [Xen-devel] [PATCH trivial v2] xen/Makefile.objs: simplify

29.12.2015 15:39, Cao jin wrote: > merge last two lines, keep alphabetic order. Applied to -trivial, thank you! /mjt ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

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

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by

[Xen-devel] [PATCH v3 17/41] 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 Acked-by: Arnd Bergmann

[Xen-devel] [PATCH v3 16/41] 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

[Xen-devel] [PATCH v3 20/41] metag: define __smp_xxx

This defines __smp_xxx barriers for metag, for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Note: as __smp_XX macros should not depend on CONFIG_SMP, they can not use the existing fence() macro since that is defined differently

[Xen-devel] [PATCH v3 19/41] 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 Acked-by: Tony Luck

[Xen-devel] [PATCH v3 21/41] mips: define __smp_xxx

This defines __smp_xxx barriers for mips, for use by virtualization. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Note: the only exception is smp_mb__before_llsc which is mips-specific. We define both the __smp_mb__before_llsc variant (for use in

[Xen-devel] [PATCH v3 18/41] 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 Acked-by: Arnd Bergmann --- arch/blackfin/include/asm/barrier.h | 4

[Xen-devel] [PATCH v3 22/41] 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

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

On Sun, 2016-01-10 at 13:57 +0200, Michael S. Tsirkin wrote: > Introduction of __smp barriers cleans up a bunch of duplicate code, but > it gives people an additional handle onto a "new" set of barriers - just > because they're prefixed with __* unfortunately doesn't stop anyone from > using it

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

On Sun, 2016-01-10 at 13:56 +0200, Michael S. Tsirkin wrote: > SMP-only barriers were missing in checkpatch.pl > > Refactor code slightly to make adding more variants easier. [] > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl [] > @@ -5116,7 +5116,25 @@ sub process { >  

[Xen-devel] [qemu-mainline test] 77632: regressions - FAIL

flight 77632 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/77632/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 77410 Regressions

[Xen-devel] [PATCH v3 41/41] s390: more efficient smp barriers

As per: lkml.kernel.org/r/20150921112252.3c2937e1@mschwide atomics imply a barrier on s390, so s390 should change smp_mb__before_atomic and smp_mb__after_atomic to barrier() instead of smp_mb() and hence should not use the generic versions. Suggested-by: Peter Zijlstra

[Xen-devel] [PATCH v3 38/41] xen/io: use virt_xxx barriers

include/xen/interface/io/ring.h uses full memory barriers to communicate with the other side. For guests compiled with CONFIG_SMP, smp_wmb and smp_mb would be sufficient, so mb() and wmb() here are only needed if a non-SMP guest runs on an SMP host. Switch to virt_xxx barriers which serve this

[Xen-devel] [PATCH v3 35/41] checkpatch: check for __smp outside barrier.h

Introduction of __smp barriers cleans up a bunch of duplicate code, but it gives people an additional handle onto a "new" set of barriers - just because they're prefixed with __* unfortunately doesn't stop anyone from using it (as happened with other arch stuff before.) Add a checkpatch test so

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

drivers/xen/events/events_fifo.c uses rmb() to communicate with the other side. For guests compiled with CONFIG_SMP, smp_rmb would be sufficient, so rmb() here is only needed if a non-SMP guest runs on an SMP host. Switch to the virt_rmb barrier which serves this exact purpose. Pull in

[Xen-devel] [PATCH v3 40/41] s390: use generic memory barriers

The s390 kernel is SMP to 99.99%, we just didn't bother with a non-smp variant for the memory-barriers. If the generic header is used we'd get the non-smp version for free. It will save a small amount of text space for CONFIG_SMP=n. Suggested-by: Martin Schwidefsky

[Xen-devel] [PATCH v3 37/41] xenbus: use virt_xxx barriers

drivers/xen/xenbus/xenbus_comms.c uses full memory barriers to communicate with the other side. For guests compiled with CONFIG_SMP, smp_wmb and smp_mb would be sufficient, so mb() and wmb() here are only needed if a non-SMP guest runs on an SMP host. Switch to virt_xxx barriers which serve this

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

On Sun, 2016-01-10 at 07:07 -0800, Joe Perches wrote: > On Sun, 2016-01-10 at 13:56 +0200, Michael S. Tsirkin wrote: > > SMP-only barriers were missing in checkpatch.pl > > > > Refactor code slightly to make adding more variants easier. > [] > > diff --git a/scripts/checkpatch.pl

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

On Sun, Jan 10, 2016 at 07:17:31AM -0800, Joe Perches wrote: > On Sun, 2016-01-10 at 07:07 -0800, Joe Perches wrote: > > On Sun, 2016-01-10 at 13:56 +0200, Michael S. Tsirkin wrote: > > > SMP-only barriers were missing in checkpatch.pl > > > > > > Refactor code slightly to make adding more

[Xen-devel] [PATCH v3 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 replaces the checkpatch patches in my series arch: barrier cleanup + barriers for virt and will be included in the next version of the series. changes from

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

Introduction of __smp barriers cleans up a bunch of duplicate code, but it gives people an additional handle onto a "new" set of barriers - just because they're prefixed with __* unfortunately doesn't stop anyone from using it (as happened with other arch stuff before.) Add a checkpatch test so

[Xen-devel] [PATCH v3 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 --- scripts/checkpatch.pl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 15cfca4..4466579

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

On Sun, Jan 10, 2016 at 07:07:05AM -0800, Joe Perches wrote: > On Sun, 2016-01-10 at 13:56 +0200, Michael S. Tsirkin wrote: > > SMP-only barriers were missing in checkpatch.pl > > > > Refactor code slightly to make adding more variants easier. > [] > > diff --git a/scripts/checkpatch.pl

Re: [Xen-devel] [PATCH v13 7/8] Add IOREQ_TYPE_VMWARE_PORT

On 12/21/15 09:10, Jan Beulich wrote: On 28.11.15 at 22:45, wrote: >> @@ -133,7 +134,7 @@ static int hvmemul_do_io( >> p = vio->io_req; >> >> /* Verify the emulation request has been correctly re-issued */ >> -if ( (p.type != is_mmio ?

[Xen-devel] Blank screen while booting xen

Hi, I tried to modify and compile some of Xen 4.7's code (cloned from git clone git://xenbits.xen.org/xen.git) and even with a very minor change (patch included at last) my xen failed to boot. It stucks at black blank screen after showing some xen logs. By adding "vga=text-80x80,keep" to the

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

On Mon, 2016-01-11 at 09:13 +1100, Julian Calaby wrote: > On Mon, Jan 11, 2016 at 6:31 AM, Michael S. Tsirkin wrote: > > Add virt_ barriers to list of barriers to check for > > presence of a comment. [] > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl [] > > @@

[Xen-devel] [xen-4.5-testing test] 77666: tolerable FAIL - PUSHED

flight 77666 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/77666/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 9 debian-install fail in 77498 pass in 77666

[Xen-devel] [qemu-upstream-4.2-testing test] 77693: regressions - FAIL

flight 77693 qemu-upstream-4.2-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/77693/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 62044