> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: 30 June 2020 18:27
> To: p...@xen.org; xen-devel@lists.xenproject.org; qemu-de...@nongnu.org
> Cc: 'Eduardo Habkost' ; 'Michael S. Tsirkin'
> ; 'Paul Durrant'
> ; 'Jason Andryuk' ; 'Paolo Bonzini'
> ;
> 'Richard Henderson'
> Su
flight 151485 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151485/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 15106
From: Oleksandr Andrushchenko
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add the version as an integer.
2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE
Ther
On Tue, Jun 30, 2020 at 06:09:13PM +0100, Anthony PERARD wrote:
> In order to get the CNT value from QEMU, we were supposed to read a
> word, according to the implementation in QEMU. But it has been lax and
> allowed to read a single byte. This has changed with commit
> 5d971f9e6725 ("memory: Rever
Hello,
I've been doing some work with the virtual timers infrastructure in
order to improve some of it's shortcomings. See:
https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00919.html
For an example of such issues, and how the emulated timers are not
architecturally correct.
It's
On Wed, Jul 01, 2020 at 09:52:57AM +0200, Roger Pau Monné wrote:
> On Tue, Jun 30, 2020 at 06:09:13PM +0100, Anthony PERARD wrote:
> > In order to get the CNT value from QEMU, we were supposed to read a
> > word, according to the implementation in QEMU. But it has been lax and
> > allowed to read a
On Tue, Jun 30, 2020 at 02:33:45PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Check if Intel Processor Trace feature is supported by current
> processor. Define vmtrace_supported global variable.
>
> Signed-off-by: Michal Leszczynski
> ---
> xen/arch/x86/hvm/vmx/vmcs.c
On 29/06/2020 08:42, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 26 June 2020 18:54
To: Stefano Stabellini ; p...@xen.org
Cc: Volodymyr Babchuk ;
xen-devel@lists.xenproject.org; op-
t...@lists.trustedfirmware.org
Subject: Re: [PATCH v2 2/2] optee: allow plain TMEM
On Tue, Jun 30, 2020 at 02:33:46PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Allow to specify the size of per-vCPU trace buffer upon
> domain creation. This is zero by default (meaning: not enabled).
>
> Signed-off-by: Michal Leszczynski
> ---
> docs/man/xl.cfg.5.pod.in
flight 151504 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151504/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 23ca7ec0ba620db52a646d80e22f9703a6589f66
baseline version:
xen 88cf
As was pointed out by 0e2e54966af5 ("mm: fix public declaration of
struct xen_mem_acquire_resource"), we're not currently handling structs
correctly that have uint64_aligned_t fields. Patch 2 demonstrates that
there was also an issue with XEN_GUEST_HANDLE_64().
Only the 1st patch was previously se
As was pointed out by 0e2e54966af5 ("mm: fix public declaration of
struct xen_mem_acquire_resource"), we're not currently handling structs
correctly that have uint64_aligned_t fields. #pragma pack(4) suppresses
the necessary alignment even if the type did properly survive (which
it also didn't) in
84e364f2eda2 ("x86: add CMCI software injection interface") merely made
sure things would build, without any concern about things actually
working:
- despite the addition of xenctl_bitmap to xlat.lst, the resulting macro
wasn't invoked anywhere (which would have lead to recognizing that the
str
Use a typedef in struct xen_mc also for the two subops "manually"
translated in the handler, just for consistency. No functional
change.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1307,16 +1307,16 @@ CHECK_mcinfo_common;
CHECK_FIELD_
This was forgotten when the subop was added.
Also take the opportunity and move the dm_op_relocate_memory entry in
xlat.lst to its designated place.
No change in the resulting generated code.
Fixes: ca2b511d3ff4 ("x86/ioreq server: add DMOP to map guest ram with
p2m_ioreq_server to an ioreq ser
The original intention was to ignore padding fields, but the pattern
matched only ones whose names started with an underscore. Also match
fields whose names are in line with the C spec by not having a leading
underscore. (Note that the leading ^ in the sed regexps was pointless
and hence get droppe
Translation macros aren't needed at all (or else a devicetree_label
entry would have been missing), and userlist has been removed quite some
time ago.
No functional change.
Signed-off-by: Jan Beulich
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -148,14 +148,11 @@
? xenoprof_in
As was already the case for XSM/Flask, avoid generating compat headers
when they're not going to be needed. To address resulting build issues
- move compat/hvm/dm_op.h inclusion to the only source file needing it,
- add a little bit of #ifdef-ary.
Signed-off-by: Jan Beulich
---
Alternatively we c
On Tue, Jun 30, 2020 at 02:33:47PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Use Intel Processor Trace feature in order to
> provision vmtrace_pt_* features.
>
> Signed-off-by: Michal Leszczynski
> ---
> xen/arch/x86/hvm/vmx/vmx.c | 89
On Tue, Jun 30, 2020 at 02:33:48PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Allocate processor trace buffer for each vCPU when the domain
> is created, deallocate trace buffers on domain destruction.
>
> Signed-off-by: Michal Leszczynski
> ---
> xen/arch/x86/domain.c
On Tue, Jun 30, 2020 at 02:33:49PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Allow to acquire large resources by allowing acquire_resource()
> to process items in batches, using hypercall continuation.
This patch should be the first of thew series IMO, since it can go in
in
On 01.07.20 09:19, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add the version as an integer.
2. P
On Tue, Jun 30, 2020 at 02:33:50PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Allow to map processor trace buffer using
> acquire_resource().
>
> Signed-off-by: Michal Leszczynski
> ---
> xen/arch/x86/mm.c | 25 +
> xen/include/public/memo
flight 151491 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151491/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 151461
Tests which did not succeed
On Tue, Jun 30, 2020 at 02:33:51PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Implement domctl to manage the runtime state of
> processor trace feature.
>
> Signed-off-by: Michal Leszczynski
> ---
> xen/arch/x86/domctl.c | 48 +
>
Tamas K Lengyel writes ("Re: [PATCH v3 7/7] tools/proctrace: add proctrace
tool"):
> On Fri, Jun 26, 2020 at 7:26 AM Ian Jackson wrote:
> > Wei Liu writes ("Re: [PATCH v3 7/7] tools/proctrace: add proctrace tool"):
> > > On Mon, Jun 22, 2020 at 08:12:56PM +0200, Michał Leszczyński wrote:
> > > >
Some paravirt macros are no longer used, delete them.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index cfe9f6e472b5..cff2fbd1edd5 100644
---
Xen is requiring 64-bit machines today and since Xen 4.14 it can be
built without 32-bit PV guest support. There is no need to carry the
burden of 32-bit PV guest support in the kernel any longer, as new
guests can be either HVM or PVH, or they can use a 64 bit kernel.
Remove the 32-bit Xen PV sup
There are some code parts using CONFIG_PARAVIRT for Xen pvops related
issues instead of the more stringent CONFIG_PARAVIRT_XXL.
Signed-off-by: Juergen Gross
---
arch/x86/entry/entry_64.S| 4 ++--
arch/x86/include/asm/fixmap.h| 2 +-
arch/x86/include/asm/required-featu
The long term plan has been to replace Xen PV guests by PVH. The first
victim of that plan are now 32-bit PV guests, as those are used only
rather seldom these days. Xen on x86 requires 64-bit support and with
Grub2 now supporting PVH officially since version 2.04 there is no
need to keep 32-bit PV
The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone.
Remove 32-bit specific parts.
Signed-off-by: Juergen Gross
---
arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 +
arch/x86/include/asm/paravirt.h | 92 +++--
arch/x86/include/asm/paravirt_types.h
Some x86 CPUs speculatively execute beyond indirect CALL/JMP instructions.
With CONFIG_INDIRECT_THUNK / Retpolines, indirect CALL/JMP instructions are
converted to direct CALL/JMP's to __x86_indirect_thunk_REG(), leaving just a
handful of indirect JMPs implementing those stubs.
There is no archit
On 7/1/20 1:46 PM, Jürgen Groß wrote:
> On 01.07.20 09:19, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> 1. Add protocol version as an integer
>>
>> Version string, which is in fact an integer, is hard to handle in the
>> code that supports different protocol versions. To s
Avoid allocating large amount of data on the stack in
xenbus_map_ring_valloc() and some related return value cleanups.
Juergen Gross (2):
xen/xenbus: avoid large structs and arrays on the stack
xen/xenbus: let xenbus_map_ring_valloc() return errno values only
drivers/xen/xenbus/xenbus_client
Today xenbus_map_ring_valloc() can return either a negative errno
value (-ENOMEM or -EINVAL) or a grant status value. This is a mess as
e.g -ENOMEM and GNTST_eagain have the same numeric value.
Fix that by turning all grant mapping errors into -ENOENT. This is
no problem as all callers of xenbus_m
xenbus_map_ring_valloc() and its sub-functions are putting quite large
structs and arrays on the stack. This is problematic at runtime, but
might also result in build failures (e.g. with clang due to the option
-Werror,-Wframe-larger-than=... used).
Fix that by moving most of the data from the sta
On Wed, Jul 1, 2020 at 3:03 AM Paul Durrant wrote:
>
> > -Original Message-
> > From: Philippe Mathieu-Daudé
> > Sent: 30 June 2020 18:27
> > To: p...@xen.org; xen-devel@lists.xenproject.org; qemu-de...@nongnu.org
> > Cc: 'Eduardo Habkost' ; 'Michael S. Tsirkin'
> > ; 'Paul Durrant'
> >
On 01.07.2020 13:58, Andrew Cooper wrote:
> Some x86 CPUs speculatively execute beyond indirect CALL/JMP instructions.
>
> With CONFIG_INDIRECT_THUNK / Retpolines, indirect CALL/JMP instructions are
> converted to direct CALL/JMP's to __x86_indirect_thunk_REG(), leaving just a
> handful of indirec
On 7/1/20 2:25 PM, Jason Andryuk wrote:
> On Wed, Jul 1, 2020 at 3:03 AM Paul Durrant wrote:
>>
>>> -Original Message-
>>> From: Philippe Mathieu-Daudé
>>> Sent: 30 June 2020 18:27
>>> To: p...@xen.org; xen-devel@lists.xenproject.org; qemu-de...@nongnu.org
>>> Cc: 'Eduardo Habkost' ; 'Mic
On 7/1/20 2:40 PM, Philippe Mathieu-Daudé wrote:
> On 7/1/20 2:25 PM, Jason Andryuk wrote:
>> On Wed, Jul 1, 2020 at 3:03 AM Paul Durrant wrote:
>>>
-Original Message-
From: Philippe Mathieu-Daudé
Sent: 30 June 2020 18:27
To: p...@xen.org; xen-devel@lists.xenproject.or
> -Original Message-
> From: Jan Beulich
> Sent: 01 July 2020 13:27
> To: Andrew Cooper
> Cc: Xen-devel ; Wei Liu ; Roger
> Pau Monné
> ; Paul Durrant
> Subject: Re: [PATCH for-4.14] x86/spec-ctrl: Protect against CALL/JMP
> straight-line speculation
>
> On 01.07.2020 13:58, Andrew Co
On Mon, Jun 29, 2020 at 04:46:09PM -0700, Stefano Stabellini wrote:
> > I could imagine some future Xen hosts setting a flag somewhere in the
> > platform capability saying "no xen specific flag, rely on
> > "VIRTIO_F_ACCESS_PLATFORM". Then you set that accordingly in QEMU.
> > How about that?
>
>
flight 151496 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151496/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151469
test-armhf-armhf-libvirt-raw 13 saveresto
On Wed, Jul 1, 2020 at 8:55 AM Philippe Mathieu-Daudé wrote:
>
> On 7/1/20 2:40 PM, Philippe Mathieu-Daudé wrote:
> > On 7/1/20 2:25 PM, Jason Andryuk wrote:
> >> On Wed, Jul 1, 2020 at 3:03 AM Paul Durrant wrote:
> >>>
> -Original Message-
> From: Philippe Mathieu-Daudé
>
On 7/1/20 4:59 PM, Jason Andryuk wrote:
> On Wed, Jul 1, 2020 at 8:55 AM Philippe Mathieu-Daudé
> wrote:
>> On 7/1/20 2:40 PM, Philippe Mathieu-Daudé wrote:
>>> On 7/1/20 2:25 PM, Jason Andryuk wrote:
On Wed, Jul 1, 2020 at 3:03 AM Paul Durrant wrote:
>
>> -Original Message-
On 30/06/2020 13:33, Michał Leszczyński wrote:
@@ -305,7 +311,6 @@ static int vmx_init_vmcs_config(void)
SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS |
SECONDARY_EXEC_XSAVES |
SECONDARY_EXEC_TSC_SCALING);
-rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap
Hi,
On 30/06/2020 13:33, Michał Leszczyński wrote:
+static int vmtrace_alloc_buffers(struct vcpu *v)
+{
+struct page_info *pg;
+uint64_t size = v->domain->vmtrace_pt_size;
+
+if ( size < PAGE_SIZE || size > GB(4) || (size & (size - 1)) )
+{
+/*
+ * We don't accept
On Fri, Jun 26, 2020 at 1:30 PM Andy Lutomirski wrote:
>
> The SYSENTER frame setup was nonsense. It worked by accident
> because the normal code into which the Xen asm jumped
> (entry_SYSENTER_32/compat) threw away SP without touching the stack.
> entry_SYSENTER_compat was recently modified such
On 01/07/2020 16:12, Julien Grall wrote:
> On 30/06/2020 13:33, Michał Leszczyński wrote:
>> @@ -305,7 +311,6 @@ static int vmx_init_vmcs_config(void)
>> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS |
>> SECONDARY_EXEC_XSAVES |
>> SECONDARY_EXEC_TSC_SCALI
On Wed, Jul 01, 2020 at 12:25:15PM +0200, Jan Beulich wrote:
> As was pointed out by 0e2e54966af5 ("mm: fix public declaration of
> struct xen_mem_acquire_resource"), we're not currently handling structs
> correctly that have uint64_aligned_t fields. #pragma pack(4) suppresses
> the necessary align
On 01/07/2020 17:06, Andrew Cooper wrote:
On 01/07/2020 16:12, Julien Grall wrote:
On 30/06/2020 13:33, Michał Leszczyński wrote:
@@ -305,7 +311,6 @@ static int vmx_init_vmcs_config(void)
SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS |
SECONDARY_EXEC_XSAVES |
On 01.07.2020 18:10, Roger Pau Monné wrote:
> On Wed, Jul 01, 2020 at 12:25:15PM +0200, Jan Beulich wrote:
>> As was pointed out by 0e2e54966af5 ("mm: fix public declaration of
>> struct xen_mem_acquire_resource"), we're not currently handling structs
>> correctly that have uint64_aligned_t fields.
On 01/07/2020 17:17, Julien Grall wrote:
On 01/07/2020 17:06, Andrew Cooper wrote:
On 01/07/2020 16:12, Julien Grall wrote:
On 30/06/2020 13:33, Michał Leszczyński wrote:
@@ -305,7 +311,6 @@ static int vmx_init_vmcs_config(void)
SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS |
On Wed, Jul 1, 2020 at 7:08 AM Juergen Gross wrote:
>
> Xen is requiring 64-bit machines today and since Xen 4.14 it can be
> built without 32-bit PV guest support. There is no need to carry the
> burden of 32-bit PV guest support in the kernel any longer, as new
> guests can be either HVM or PVH,
On 01/07/2020 17:18, Julien Grall wrote:
>
>
> On 01/07/2020 17:17, Julien Grall wrote:
>>
>>
>> On 01/07/2020 17:06, Andrew Cooper wrote:
>>> On 01/07/2020 16:12, Julien Grall wrote:
On 30/06/2020 13:33, Michał Leszczyński wrote:
> @@ -305,7 +311,6 @@ static int vmx_init_vmcs_config(void)
On Wed, 1 Jul 2020, Christoph Hellwig wrote:
> On Mon, Jun 29, 2020 at 04:46:09PM -0700, Stefano Stabellini wrote:
> > > I could imagine some future Xen hosts setting a flag somewhere in the
> > > platform capability saying "no xen specific flag, rely on
> > > "VIRTIO_F_ACCESS_PLATFORM". Then you s
On 30/06/2020 13:33, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Define constants related to Intel Processor Trace features.
>
> Signed-off-by: Michal Leszczynski
Acked-by: Andrew Cooper
I wanted to have a play with the series, and have ended up having to do
the rebase anyway.
As
Hi,
On 01/07/2020 18:26, Andrew Cooper wrote:
On 01/07/2020 17:18, Julien Grall wrote:
On 01/07/2020 17:17, Julien Grall wrote:
On 01/07/2020 17:06, Andrew Cooper wrote:
On 01/07/2020 16:12, Julien Grall wrote:
On 30/06/2020 13:33, Michał Leszczyński wrote:
@@ -305,7 +311,6 @@ static in
On 01/07/2020 19:02, Julien Grall wrote:
> Hi,
>
> On 01/07/2020 18:26, Andrew Cooper wrote:
>> On 01/07/2020 17:18, Julien Grall wrote:
>>>
>>>
>>> On 01/07/2020 17:17, Julien Grall wrote:
On 01/07/2020 17:06, Andrew Cooper wrote:
> On 01/07/2020 16:12, Julien Grall wrote:
>
On 01/07/2020 19:06, Andrew Cooper wrote:
On 01/07/2020 19:02, Julien Grall wrote:
Hi,
On 01/07/2020 18:26, Andrew Cooper wrote:
On 01/07/2020 17:18, Julien Grall wrote:
On 01/07/2020 17:17, Julien Grall wrote:
On 01/07/2020 17:06, Andrew Cooper wrote:
On 01/07/2020 16:12, Julien Gra
flight 151494 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151494/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
Tests which are fa
On Wed, Jul 1, 2020 at 8:42 AM Brian Gerst wrote:
>
> On Fri, Jun 26, 2020 at 1:30 PM Andy Lutomirski wrote:
> >
> > The SYSENTER frame setup was nonsense. It worked by accident
> > because the normal code into which the Xen asm jumped
> > (entry_SYSENTER_32/compat) threw away SP without touchin
flight 151511 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151511/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed, Jul 01, 2020 at 10:34:53AM -0700, Stefano Stabellini wrote:
> On Wed, 1 Jul 2020, Christoph Hellwig wrote:
> > On Mon, Jun 29, 2020 at 04:46:09PM -0700, Stefano Stabellini wrote:
> > > > I could imagine some future Xen hosts setting a flag somewhere in the
> > > > platform capability saying
flight 151503 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151503/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 151339
Tests which did not s
flight 151500 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151500/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 15106
On Wed, Jul 01, 2020 at 10:34:53AM -0700, Stefano Stabellini wrote:
> Would you be in favor of a more flexible check along the lines of the
> one proposed in the patch that started this thread:
>
> if (xen_vring_use_dma())
> return true;
>
>
> xen_vring_use_dma would be implement
On 30/06/2020 13:33, Michał Leszczyński wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index ca94c2bedc..b73d824357 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -291,6 +291,12 @@ static int vmx_init_vmcs_config(void)
>
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-xsm
testid guest-start
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbit
flight 151515 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151515/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hello xen experts:
Is there any way to save xen and dom0 core dump log when xen
or dom0 crash on ARM64 platform?
I find that the kdump seems can't run on ARM64 platform?
Are there any patches or other way to achive this goal?
Thank you very much!
Jason Andryuk writes:
> On Wed, Jul 1, 2020 at 3:03 AM Paul Durrant wrote:
>>
>> > -Original Message-
>> > From: Philippe Mathieu-Daudé
>> > Sent: 30 June 2020 18:27
>> > To: p...@xen.org; xen-devel@lists.xenproject.org; qemu-de...@nongnu.org
>> > Cc: 'Eduardo Habkost' ; 'Michael S. Tsi
flight 151506 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151506/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail pass in 151491
Tests which did not succeed, but
73 matches
Mail list logo
