[Xen-devel] [linux-3.18 baseline-only test] 72446: regressions - FAIL

This run is configured for baseline tests only. flight 72446 linux-3.18 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72446/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run:

Re: [Xen-devel] [PATCH] xen/pvcalls: fix potential endless loop in pvcalls-front.c

On 11/14/2017 04:11 AM, Juergen Gross wrote: > On 13/11/17 19:33, Stefano Stabellini wrote: >> On Mon, 13 Nov 2017, Juergen Gross wrote: >>> On 11/11/17 00:57, Stefano Stabellini wrote: On Tue, 7 Nov 2017, Juergen Gross wrote: > On 06/11/17 23:17, Stefano Stabellini wrote: >>

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

On Tue, Nov 14, 2017 at 12:49 PM, Andre Przywara wrote: > Hi, Hi Andre > > On 13/11/17 19:40, Oleksandr Tyshchenko wrote: >> On Mon, Nov 13, 2017 at 5:21 PM, Andre Przywara >> wrote: >>> Hi, >> Hi Andre, >> >>> >>> thanks very much for your

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

flight 116156 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/116156/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 116126 Tests

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

flight 116164 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/116164/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore.2 fail REGR. vs. 115643

[Xen-devel] [linux-4.1 baseline-only test] 72447: regressions - trouble: broken/fail/pass

This run is configured for baseline tests only. flight 72447 linux-4.1 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72447/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386

[Xen-devel] [xen-unstable test] 116161: tolerable FAIL - PUSHED

flight 116161 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/116161/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 116108 test-armhf-armhf-libvirt-xsm 14

Re: [Xen-devel] [RFC v2 5/7] acpi:arm64: Add support for parsing IORT table

On 11/8/2017 7:41 AM, Manish Jaggi wrote: > Hi Sameer > > On 9/21/2017 6:07 AM, Sameer Goel wrote: >> Add support for parsing IORT table to initialize SMMU devices. >> * The code for creating an SMMU device has been modified, so that the SMMU >> device can be initialized. >> * The NAMED NODE

Re: [Xen-devel] Unable to create guest PV domain on OMAP5432

Hello Andrii, >> BTW, what is your dom0 system? Does it have bash? > *dom0 uses a modified kernel(3.15) with Xen support and default omap fs* I made certain changes to my configuration file. Instead of trying to use a disk, I want to the guest domain up from ramdisk image. My new

[Xen-devel] [seabios test] 116168: regressions - FAIL

flight 116168 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/116168/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which are

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

On 15 November 2017 at 02:16, Oleksandr Tyshchenko wrote: > On Tue, Nov 14, 2017 at 12:49 PM, Andre Przywara > wrote: > > 3. Direct ported SCPI protocol, mailbox infrastructure and the ARM SMC > triggered mailbox driver. All components

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

flight 116173 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/116173/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm 20 guest-start/debian.repeat fail REGR. vs. 116126

Re: [Xen-devel] [PATCH for-4.10] libs/evtchn: Remove active handler on clean-up or failure

On 11/14/2017 11:51 AM, Ian Jackson wrote: Ross Lagerwall writes ("Re: [PATCH for-4.10] libs/evtchn: Remove active handler on clean-up or failure"): On 11/10/2017 05:10 PM, Julien Grall wrote: Commit 89d55473ed16543044a31d1e0d4660cf5a3f49df "xentoolcore_restrict_all: Implement for

Re: [Xen-devel] [PATCH for-4.10] libs/evtchn: Remove active handler on clean-up or failure

Ross Lagerwall writes ("Re: [PATCH for-4.10] libs/evtchn: Remove active handler on clean-up or failure"): > Now that I look at it, a similar scenario can happen during open. Since > the handle is registered before it is actually opened, a concurrent > xentoolcore_restrict_all() will try to

Re: [Xen-devel] [PATCH v1 0/6] libxl: create standalone vkb device

On Wed, Nov 1, 2017 at 5:05 PM, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > Changes since initial: > * add setting backend-type to xenstore > * add id field to indentify the vkb device on backend side > > Oleksandr Grytsov (6): >

Re: [Xen-devel] [RFC] [Draft Design v2] ACPI/IORT Support in Xen.

Hi Manish, On 08/11/17 14:38, Manish Jaggi wrote: ACPI/IORT Support in Xen. -- Draft 2 Revision History: Changes since v1- - Modified IORT Parsing data structures. - Added RID->StreamID and RID->DeviceID map as per Andre's suggestion. - Added reference code which

Re: [Xen-devel] [PATCH 14/16] SUPPORT.md: Add statement on PCI passthrough

On Mon, Nov 13, 2017 at 03:41:24PM +, George Dunlap wrote: > Signed-off-by: George Dunlap > --- > CC: Ian Jackson > CC: Wei Liu > CC: Andrew Cooper > CC: Jan Beulich > CC:

Re: [Xen-devel] [PATCH for-4.10] libs/evtchn: Remove active handler on clean-up or failure

Hi, On 14/11/17 11:51, Ian Jackson wrote: Ross Lagerwall writes ("Re: [PATCH for-4.10] libs/evtchn: Remove active handler on clean-up or failure"): On 11/10/2017 05:10 PM, Julien Grall wrote: Commit 89d55473ed16543044a31d1e0d4660cf5a3f49df "xentoolcore_restrict_all: Implement for

Re: [Xen-devel] [PATCH v3 for-4.10 1/2] x86/mm: fix potential race conditions in map_pages_to_xen().

Hi, On 14/11/17 08:20, Jan Beulich wrote: On 14.11.17 at 07:53, wrote: From: Min He In map_pages_to_xen(), a L2 page table entry may be reset to point to a superpage, and its corresponding L1 page table need be freed in such scenario, when these

Re: [Xen-devel] [PATCH v1 0/5] libxl: add PV sound device

On Wed, Nov 1, 2017 at 5:04 PM, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > This patch set adds PV sound device support to xl.cfg and xl. > See sndif.h for protocol implementation details. > > Changes since initial: > * fix code style >

[Xen-devel] [libvirt test] 116153: regressions - FAIL

flight 116153 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/116153/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 115476 build-armhf-libvirt

Re: [Xen-devel] [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

On 14/11/17 12:43, Quan Xu wrote: > > > On 2017/11/14 18:27, Juergen Gross wrote: >> On 14/11/17 10:38, Quan Xu wrote: >>> >>> On 2017/11/14 15:30, Juergen Gross wrote: On 14/11/17 08:02, Quan Xu wrote: > On 2017/11/13 18:53, Juergen Gross wrote: >> On 13/11/17 11:06, Quan Xu wrote:

[Xen-devel] [PATCH] tools: xentoolcore_restrict_all: Do deregistration before close

Closing the fd before unhooking it from the list runs the risk that a concurrent thread calls xentoolcore_restrict_all will operate on the old fd value, which might refer to a new fd by then. So we need to do it in the other order. Sadly this weakens the guarantee provided by

[Xen-devel] [linux-3.18 test] 116140: tolerable FAIL - PUSHED

flight 116140 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/116140/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail in 116106 pass in 116140

Re: [Xen-devel] [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

2017-11-14 16:15 GMT+08:00 Quan Xu : > > > On 2017/11/14 15:12, Wanpeng Li wrote: >> >> 2017-11-14 15:02 GMT+08:00 Quan Xu : >>> >>> >>> On 2017/11/13 18:53, Juergen Gross wrote: On 13/11/17 11:06, Quan Xu wrote: > > From: Quan Xu

Re: [Xen-devel] [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

On 2017/11/14 15:12, Wanpeng Li wrote: 2017-11-14 15:02 GMT+08:00 Quan Xu : On 2017/11/13 18:53, Juergen Gross wrote: On 13/11/17 11:06, Quan Xu wrote: From: Quan Xu So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called in idle path

Re: [Xen-devel] [PATCH v3 for-4.10 1/2] x86/mm: fix potential race conditions in map_pages_to_xen().

>>> On 14.11.17 at 07:53, wrote: > From: Min He > > In map_pages_to_xen(), a L2 page table entry may be reset to point to > a superpage, and its corresponding L1 page table need be freed in such > scenario, when these L1 page table entries are

Re: [Xen-devel] [PATCH v3 for-4.10 2/2] x86/mm: fix a potential race condition in modify_xen_mappings().

>>> On 14.11.17 at 07:53, wrote: > In modify_xen_mappings(), a L1/L2 page table shall be freed, > if all entries of this page table are empty. Corresponding > L2/L3 PTE will need be cleared in such scenario. > > However, concurrent paging structure modifications on

[Xen-devel] [seabios test] 116148: regressions - FAIL

flight 116148 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/116148/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which did not

Re: [Xen-devel] [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

On 2017/11/14 18:27, Juergen Gross wrote: On 14/11/17 10:38, Quan Xu wrote: On 2017/11/14 15:30, Juergen Gross wrote: On 14/11/17 08:02, Quan Xu wrote: On 2017/11/13 18:53, Juergen Gross wrote: On 13/11/17 11:06, Quan Xu wrote: From: Quan Xu So far, pv_idle_ops.poll

Re: [Xen-devel] [PATCH 1/4 v3 for-4.10] libxl: Fix the bug introduced in commit "libxl: use correct type modifier for vuart_gfn"

Hi, On 14 Nov 2017 3:35 pm, "Wei Liu" wrote: > On Mon, Nov 13, 2017 at 03:56:23PM +, Julien Grall wrote: > > Hi Wei, > > > > Sorry I missed that e-mail. > > > > On 10/31/2017 10:07 AM, Wei Liu wrote: > > > Change the tag to for-4.10. > > > > > > Julien, this is needed

Re: [Xen-devel] [PATCH for-4.10] libs/evtchn: Remove active handler on clean-up or failure

Ross Lagerwall writes ("Re: [PATCH for-4.10] libs/evtchn: Remove active handler on clean-up or failure"): > On 11/10/2017 05:10 PM, Julien Grall wrote: > > Commit 89d55473ed16543044a31d1e0d4660cf5a3f49df "xentoolcore_restrict_all: > > Implement for libxenevtchn" added a call to register allowing

Re: [Xen-devel] [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

On 2017/11/14 15:30, Juergen Gross wrote: On 14/11/17 08:02, Quan Xu wrote: On 2017/11/13 18:53, Juergen Gross wrote: On 13/11/17 11:06, Quan Xu wrote: From: Quan Xu So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called in idle path which will poll for

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

flight 116146 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/116146/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm 7 xen-boot fail REGR. vs. 116126 Tests which did

Re: [Xen-devel] [PATCH 1/4 v3 for-4.10] libxl: Fix the bug introduced in commit "libxl: use correct type modifier for vuart_gfn"

On Mon, Nov 13, 2017 at 03:56:23PM +, Julien Grall wrote: > Hi Wei, > > Sorry I missed that e-mail. > > On 10/31/2017 10:07 AM, Wei Liu wrote: > > Change the tag to for-4.10. > > > > Julien, this is needed to fix vuart emulation. > > To confirm, only patch #1 is candidate for Xen 4.10,

Re: [Xen-devel] [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

On 14/11/17 10:38, Quan Xu wrote: > > > On 2017/11/14 15:30, Juergen Gross wrote: >> On 14/11/17 08:02, Quan Xu wrote: >>> >>> On 2017/11/13 18:53, Juergen Gross wrote: On 13/11/17 11:06, Quan Xu wrote: > From: Quan Xu > > So far, pv_idle_ops.poll is the

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

Hi, On 13/11/17 19:40, Oleksandr Tyshchenko wrote: > On Mon, Nov 13, 2017 at 5:21 PM, Andre Przywara > wrote: >> Hi, > Hi Andre > >> >> thanks very much for your work on this! > Thank you for your comments. > >> >> On 09/11/17 17:09, Oleksandr Tyshchenko wrote: >>>

Re: [Xen-devel] [PATCH] xen/pvcalls: fix potential endless loop in pvcalls-front.c

On 13/11/17 19:33, Stefano Stabellini wrote: > On Mon, 13 Nov 2017, Juergen Gross wrote: >> On 11/11/17 00:57, Stefano Stabellini wrote: >>> On Tue, 7 Nov 2017, Juergen Gross wrote: On 06/11/17 23:17, Stefano Stabellini wrote: > mutex_trylock() returns 1 if you take the lock and 0 if not.

[Xen-devel] [linux-4.1 test] 116145: tolerable FAIL - PUSHED

flight 116145 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/116145/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail in 116104 pass in 116145 test-armhf-armhf-xl-arndale

Re: [Xen-devel] [PATCH v5 02/29] Replace all occurances of __FUNCTION__ with __func__

On Mon, Nov 13, 2017 at 02:34:42PM -0800, Alistair Francis wrote: > Replace all occurs of __FUNCTION__ except for the check in checkpatch > with the non GCC specific __func__. > > One line in hcd-musb.c was manually tweaked to pass checkpatch. > > Signed-off-by: Alistair Francis

Re: [Xen-devel] [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

On 2017/11/14 16:22, Wanpeng Li wrote: 2017-11-14 16:15 GMT+08:00 Quan Xu : On 2017/11/14 15:12, Wanpeng Li wrote: 2017-11-14 15:02 GMT+08:00 Quan Xu : On 2017/11/13 18:53, Juergen Gross wrote: On 13/11/17 11:06, Quan Xu wrote: From: Quan Xu

[Xen-devel] [xen-unstable baseline-only test] 72444: regressions - FAIL

This run is configured for baseline tests only. flight 72444 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72444/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 6 xen-install

Re: [Xen-devel] [PATCH] tools: xentoolcore_restrict_all: Do deregistration before close

Hi, On 14/11/17 14:02, Wei Liu wrote: On Tue, Nov 14, 2017 at 12:15:42PM +, Ian Jackson wrote: Closing the fd before unhooking it from the list runs the risk that a concurrent thread calls xentoolcore_restrict_all will operate on the old fd value, which might refer to a new fd by then. So

Re: [Xen-devel] [PATCH] tools: xentoolcore_restrict_all: Do deregistration before close

Ross Lagerwall writes ("Re: [PATCH] tools: xentoolcore_restrict_all: Do deregistration before close"): > On 11/14/2017 12:15 PM, Ian Jackson wrote: > > + * Note for multi-threaded programs: If xentoolcore_restrict_all is > > + * called concurrently with a function which /or closes Xen library >

[Xen-devel] [xen-unstable test] 116150: regressions - FAIL

flight 116150 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/116150/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 116132

[Xen-devel] [xen-unstable-smoke test] 116158: tolerable all pass - PUSHED

flight 116158 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/116158/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl

[Xen-devel] [distros-debian-snapshot test] 72445: tolerable FAIL

flight 72445 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72445/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail like 72430

Re: [Xen-devel] [PATCH for-4.10] libs/evtchn: Remove active handler on clean-up or failure

On Tue, Nov 14, 2017 at 12:14:14PM +, Julien Grall wrote: > Hi, > > On 14/11/17 11:51, Ian Jackson wrote: > > Ross Lagerwall writes ("Re: [PATCH for-4.10] libs/evtchn: Remove active > > handler on clean-up or failure"): > > > On 11/10/2017 05:10 PM, Julien Grall wrote: > > > > Commit

Re: [Xen-devel] [PATCH 1/4 v3 for-4.10] libxl: Fix the bug introduced in commit "libxl: use correct type modifier for vuart_gfn"

On Tue, Nov 14, 2017 at 05:12:26PM +0530, Bhupinder Thakur wrote: > Hi, > > On 14 Nov 2017 3:35 pm, "Wei Liu" wrote: > > > On Mon, Nov 13, 2017 at 03:56:23PM +, Julien Grall wrote: > > > Hi Wei, > > > > > > Sorry I missed that e-mail. > > > > > > On 10/31/2017 10:07 AM,

Re: [Xen-devel] [PATCH] tools: xentoolcore_restrict_all: Do deregistration before close

On 11/14/2017 12:15 PM, Ian Jackson wrote: Closing the fd before unhooking it from the list runs the risk that a concurrent thread calls xentoolcore_restrict_all will operate on the old fd value, which might refer to a new fd by then. So we need to do it in the other order. Sadly this weakens

Re: [Xen-devel] [PATCH for-4.10] libs/evtchn: Remove active handler on clean-up or failure

Hi Wei, On 14/11/17 13:53, Wei Liu wrote: On Tue, Nov 14, 2017 at 12:14:14PM +, Julien Grall wrote: Hi, On 14/11/17 11:51, Ian Jackson wrote: Ross Lagerwall writes ("Re: [PATCH for-4.10] libs/evtchn: Remove active handler on clean-up or failure"): On 11/10/2017 05:10 PM, Julien Grall

Re: [Xen-devel] [PATCH for-4.10] tools: xentoolcore_restrict_all: Do deregistration before close

Julien Grall writes ("Re: [PATCH] tools: xentoolcore_restrict_all: Do deregistration before close"): > I think this is 4.10 material, xentoolcore was introduced in this > release and it would be good to have it right from now. I want to > confirm that you are both happy with that? Yes,

Re: [Xen-devel] [PATCH] x86/hvm: Fix rcu_unlock_domain call bypass

>>> On 14.11.17 at 16:11, wrote: > rcu_lock_current_domain is called at the beginning of do_altp2m_op, but > the altp2m_vcpu_enable_notify subop handler might skip calling > rcu_unlock_domain, possibly hanging the domain altogether. I fully agree with the change, but the

Re: [Xen-devel] [PATCH v3 for-4.10 1/2] x86/mm: fix potential race conditions in map_pages_to_xen().

On 11/14/2017 8:32 PM, Julien Grall wrote: Hi, On 14/11/17 08:20, Jan Beulich wrote: On 14.11.17 at 07:53, wrote: From: Min He In map_pages_to_xen(), a L2 page table entry may be reset to point to a superpage, and its corresponding L1 page

Re: [Xen-devel] [PATCH] x86/hvm: Fix rcu_unlock_domain call bypass

On 14/11/17 15:11, Adrian Pop wrote: > rcu_lock_current_domain is called at the beginning of do_altp2m_op, but > the altp2m_vcpu_enable_notify subop handler might skip calling > rcu_unlock_domain, possibly hanging the domain altogether. > > Signed-off-by: Adrian Pop

Re: [Xen-devel] [PATCH] x86/hvm: Fix rcu_unlock_domain call bypass

Hello, On Tue, Nov 14, 2017 at 08:25:57AM -0700, Jan Beulich wrote: > >>> On 14.11.17 at 16:11, wrote: > > rcu_lock_current_domain is called at the beginning of do_altp2m_op, but > > the altp2m_vcpu_enable_notify subop handler might skip calling > > rcu_unlock_domain,

Re: [Xen-devel] [PATCH] tools: xentoolcore_restrict_all: Do deregistration before close

On Tue, Nov 14, 2017 at 12:15:42PM +, Ian Jackson wrote: > Closing the fd before unhooking it from the list runs the risk that a > concurrent thread calls xentoolcore_restrict_all will operate on the > old fd value, which might refer to a new fd by then. So we need to do > it in the other

[Xen-devel] [PATCH] x86/hvm: Fix rcu_unlock_domain call bypass

rcu_lock_current_domain is called at the beginning of do_altp2m_op, but the altp2m_vcpu_enable_notify subop handler might skip calling rcu_unlock_domain, possibly hanging the domain altogether. Signed-off-by: Adrian Pop --- xen/arch/x86/hvm/hvm.c | 8 +++- 1 file

[Xen-devel] [seabios test] 116154: regressions - FAIL

flight 116154 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/116154/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which are

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

flight 116152 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/116152/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 17 guest-start.2fail REGR. vs. 115628 build-amd64-pvops

[Xen-devel] [xen-unstable-smoke test] 116162: tolerable all pass - PUSHED

flight 116162 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/116162/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl