On 13.11.19 14:47, Jan Beulich wrote:
On 13.11.2019 01:15, Boris Ostrovsky wrote:
On 11/11/19 9:46 AM, Jan Beulich wrote:
There's no apparent reason why it can be used on 64-bit only.
Signed-off-by: Jan Beulich
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -285,7 +285,7 @@ config
On 13.11.19 19:36, Andrew Cooper wrote:
For system with large numbers of CPUs, the 'r' debugkey is unwieldy. Sibling
and core masks are a single block of adjacent bits, so are vastly shorter to
render with %pbl.
Before:
(XEN) CPU[00] nr_run=0, sort=157,
On 13.11.19 18:26, Andrew Cooper wrote:
On 13/11/2019 16:22, Juergen Gross wrote:
Debugger support in the hypervisor is rarely used and it is opening a
way for dom0 to modify the running hypervisor by very easy means.
Add a Kconfig option to control support of gdbsx. Default is off.
On Tue, 12 Nov 2019, 11:45 Peng Fan, wrote:
> Hi Julien,
>
> Inline marked with [Peng Fan]
>
> From: Julien Grall
> Sent: 2019年11月9日 6:44
> To: Stefano Stabellini ; Andre Przywara <
> andre.przyw...@arm.com>
> Cc: Peng Fan ; Jürgen Groß ;
> julien.gr...@arm.com; xen-de...@lists.xen.org
>
On 14.11.19 00:06, osstest service owner wrote:
flight 144067 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144067/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
flight 144073 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144073/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144025
Tests
From: Julian Tuminaro and Jenish Rakholiya
Current implementation of find_os is based on the hard-coded values for
different Windows version. It uses the value for get the address to
start looking for DOS header in the given specified range. However, this
is not scalable to all version of
On Thu, 14 Nov 2019, 02:15 Artem Mygaiev, wrote:
> Hi Jan,
>
> Sorry for delayed reply
>
> On Thu, 2019-11-07 at 08:31 +0100, Jan Beulich wrote:
> > On 06.11.2019 23:08, Artem Mygaiev wrote:
> > > On Wed, Nov 6, 2019 at 4:28 PM Jan Beulich <
> > > jbeul...@suse.com
> > > > wrote:
> > > > On
On Tue, 12 Nov 2019, 05:57 Stefano Stabellini,
wrote:
> On Wed, 6 Nov 2019, Andrii Anisov wrote:
> > From: Andrii Anisov
> >
> > ARM Compiler 6 has a proven bug: it compiles data only C files with
> > SoftVFP attributes. This leads to a failed linkage afterwards with
> > an error:
> >
> >
flight 144070 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144070/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 144050
test-armhf-armhf-xl-rtds
Hello All,
I came across the following: https://lkml.org/lkml/2019/8/29/536
Could that be the reason for the problem mentioned below? Xen is using
HPET as clocksource on the platform/mainboard. Is there an (easy) way to
verify if Xen uses PC10?
Regards Andreas
On 12.10.2019 20:47, Andreas
flight 144067 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144067/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail REGR.
> What's the point of this?
>
> I realize it's slightly annoying to have to type `mac[0], mac[1], ...`,
> but I'd rather do that once than make the runtime copy everything over
> into a slice of interfaces every String() call.
As I think you realized by looking at subsequent patches, this is to
Ran same test and did not hit the issue.
Tested-by: Joe Jin
On 11/13/19 7:59 AM, Roger Pau Monne wrote:
> When using posted interrupts and the guest migrates MSI from vCPUs Xen
> needs to flush any pending PIRR vectors on the previous vCPU, or else
> those vectors could get wrongly injected at
> Doesn't this method want a pointer receiver?
Yes, since I'm allocating a new slice. If I wasn't allocating a new
slice, this would be okay since the slice contains a pointer to the
underlying array.
-NR
___
Xen-devel mailing list
flight 144068 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144068/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bfcf262488a140550a53361c225a9b2b1bee0db8
baseline version:
ovmf
> Any particular reason to use `cslice` here rather than `mapslice` (or
> vice versa)?
>
> Not a big deal, but since they're of the came element in the C struct,
> it seems like it would be better to give them the same name. (Don't
> have a strong opinion on which one).
IIRC, I found the name
On Wed, Nov 13, 2019 at 9:52 AM Jan Beulich wrote:
>
> On 13.11.2019 15:57, Tamas K Lengyel wrote:
> > On Wed, Nov 13, 2019 at 7:51 AM Tamas K Lengyel wrote:
> >>
> >> On Tue, Nov 12, 2019 at 7:31 AM Jan Beulich wrote:
> >>>
> >>> On 12.11.2019 15:05, Tamas K Lengyel wrote:
> On Tue, Nov
For system with large numbers of CPUs, the 'r' debugkey is unwieldy. Sibling
and core masks are a single block of adjacent bits, so are vastly shorter to
render with %pbl.
Before:
(XEN) CPU[00] nr_run=0, sort=157,
On 10/7/19 4:13 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Re-define Hwcap as [8]uint32, and implement toC function. Also, re-name and
> modify signature of toGo function to fromC.
>
> Signed-off-by: Nick Rosbrook
Looks good. Just one comment...
> ---
> Cc: George Dunlap
> Cc: Ian
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Re-define Uuid as [16]byte and implement fromC, toC, and String functions.
>
> Signed-off-by: Nick Rosbrook
> ---
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Wei Liu
>
> tools/golang/xenlight/xenlight.go | 37
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Define CpuidPolicyList as a wrapper struct with field val of type
> *C.libxl_cpuid_policy_list and implement fromC and toC functions.
>
> Signed-off-by: Nick Rosbrook
> ---
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Wei Liu
flight 144082 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144082/
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
On 13/11/2019 16:22, Juergen Gross wrote:
> Debugger support in the hypervisor is rarely used and it is opening a
> way for dom0 to modify the running hypervisor by very easy means.
>
> Add a Kconfig option to control support of gdbsx. Default is off.
>
> Signed-off-by: Juergen Gross
> ---
>
Hi Jan,
Sorry for delayed reply
On Thu, 2019-11-07 at 08:31 +0100, Jan Beulich wrote:
> On 06.11.2019 23:08, Artem Mygaiev wrote:
> > On Wed, Nov 6, 2019 at 4:28 PM Jan Beulich <
> > jbeul...@suse.com
> > > wrote:
> > > On 06.11.2019 10:19, Andrii Anisov wrote:
> > > > --- a/Config.mk
> > > >
Dear Julien,
On 13.11.19 07:51, Julien Grall wrote:
Was this reported to Arm?
All mentioned ARM Compiler issues were reported to ARM. Unfortunately, ARM
hesitated to discus them in community, yet asked to open support cases, e.g.
[1].
All issues and their WA's were acknowledged by ARM in
There were two problems here: The first closing parentheses got parsed
by make to end the $(call invocation, and the escaping of the quotes
wasn't right either, as there's nowhere they would get un-escaped.
Signed-off-by: Jan Beulich
---
This needs to be tested in an environment where this was
On 13.11.2019 17:22, Juergen Gross wrote:
> Debugger support in the hypervisor is rarely used and it is opening a
> way for dom0 to modify the running hypervisor by very easy means.
>
> Add a Kconfig option to control support of gdbsx. Default is off.
>
> Signed-off-by: Juergen Gross
Acked-by:
On 13.11.2019 15:57, Tamas K Lengyel wrote:
> On Wed, Nov 13, 2019 at 7:51 AM Tamas K Lengyel wrote:
>>
>> On Tue, Nov 12, 2019 at 7:31 AM Jan Beulich wrote:
>>>
>>> On 12.11.2019 15:05, Tamas K Lengyel wrote:
On Tue, Nov 12, 2019 at 4:54 AM Jan Beulich wrote:
> On 06.11.2019 16:35,
On Wed, Nov 13, 2019 at 05:59:52AM -0800, Christoph Hellwig wrote:
> > +int mmu_interval_notifier_insert(struct mmu_interval_notifier *mni,
> > + struct mm_struct *mm, unsigned long start,
> > + unsigned long length,
> > +
Hello Stefano,
On 11.11.19 22:57, Stefano Stabellini wrote:
Oh man, this is truly horrible.
I feel your pain.
If we really have to do this please:
- use the same dummy function name in all files
No, because
- the function should be static
those functions will not handle the case if
On 11/13/19 8:44 AM, Jan Beulich wrote:
> On 13.11.2019 01:11, Boris Ostrovsky wrote:
>> On 11/11/19 9:46 AM, Jan Beulich wrote:
>>> --- a/arch/x86/include/asm/msr-index.h
>>> +++ b/arch/x86/include/asm/msr-index.h
>>> @@ -393,6 +393,8 @@
>>> #define MSR_AMD_PSTATE_DEF_BASE0xc0010064
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Define EvLink as empty struct as there is currently no reason the internal of
> this type should be used in Go.
>
> Implement fromC and toC functions as no-ops.
>
> Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
Debugger support in the hypervisor is rarely used and it is opening a
way for dom0 to modify the running hypervisor by very easy means.
Add a Kconfig option to control support of gdbsx. Default is off.
Signed-off-by: Juergen Gross
---
xen/Kconfig.debug | 4
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Define MsVmGenid as [int(C.LIBXL_MS_VM_GENID_LEN)]byte and implement fromC
> and toC functions.
>
> Signed-off-by: Nick Rosbrook
> ---
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Wei Liu
>
>
... if the vCPU is different than the one currently running or if it's
running on a different pCPU.
No functional change intended.
Suggested by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Cc: Juergen Gross
---
xen/arch/x86/hvm/vmx/vmx.c | 11 +++
1 file changed, 11
If posted interrutps are being used sync PIR to IRR when an unmasked
vIO-APIC entry is modified. Do this in order to prevent vectors in the
IRR being set after a change to a vIO-APIC entry has been performed.
Signed-off-by: Roger Pau Monné
---
Cc: Juergen Gross
---
xen/arch/x86/hvm/vioapic.c |
When using posted interrupts and the guest migrates MSI from vCPUs Xen
needs to flush any pending PIRR vectors on the previous vCPU, or else
those vectors could get wrongly injected at a later point when the MSI
fields are already updated.
The usage of a fixed vCPU in lowest priority mode when
Hello,
The current interrupt posting code doesn't flush the PIR into the IRR
when interrupts are modified, and as a result a vCPU can receive vectors
from a tear down or moved interrupt. Fix this by making sure PIR is
always synced to IRR when vMSI or vIO-APIC interrupts are modified.
Roger Pau
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Define Mac as [6]byte and implement fromC, toC, and String functions.
>
> Signed-off-by: Nick Rosbrook
> ---
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Wei Liu
>
> tools/golang/xenlight/xenlight.go | 35
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Define StringList as []string an implement fromC and toC functions.
>
> Signed-off-by: Nick Rosbrook
> ---
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Wei Liu
>
> tools/golang/xenlight/xenlight.go | 29
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Re-name and modify signature of toGo function to fromC. The reason for
> using 'fromC' rather than 'toGo' is that it is not a good idea to define
> methods on the C types. Also, add error return type to Bitmap's toC function.
>
On 13/11/2019 14:42, Jan Beulich wrote:
> On 13.11.2019 12:55, osstest service owner wrote:
>> flight 144059 xen-4.12-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/144059/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which
On Wed, Nov 13, 2019 at 7:51 AM Tamas K Lengyel wrote:
>
> On Tue, Nov 12, 2019 at 7:31 AM Jan Beulich wrote:
> >
> > On 12.11.2019 15:05, Tamas K Lengyel wrote:
> > > On Tue, Nov 12, 2019 at 4:54 AM Jan Beulich wrote:
> > >> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
> > >>> +
On Tue, Nov 12, 2019 at 7:31 AM Jan Beulich wrote:
>
> On 12.11.2019 15:05, Tamas K Lengyel wrote:
> > On Tue, Nov 12, 2019 at 4:54 AM Jan Beulich wrote:
> >> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
> >>> +else
> >>> +{
> >>> +rc =
On 13.11.2019 15:40, Jürgen Groß wrote:
> On 13.11.19 15:07, Jan Beulich wrote:
>> On 12.11.2019 17:06, Jürgen Groß wrote:
>>> On 12.11.19 14:48, Jan Beulich wrote:
On 02.10.2019 13:20, Juergen Gross wrote:
> +static unsigned int hypfs_get_entry_len(struct hypfs_entry *entry)
> +{
On 13.11.2019 12:55, osstest service owner wrote:
> flight 144059 xen-4.12-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/144059/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
On 13.11.19 15:12, Jan Beulich wrote:
On 12.11.2019 17:45, Jürgen Groß wrote:
On 12.11.19 15:22, Jan Beulich wrote:
On 02.10.2019 13:20, Juergen Gross wrote:
@@ -79,3 +80,11 @@ subdir-$(CONFIG_UBSAN) += ubsan
subdir-$(CONFIG_NEEDS_LIBELF) += libelf
subdir-$(CONFIG_HAS_DEVICE_TREE)
On 13.11.19 15:07, Jan Beulich wrote:
On 12.11.2019 17:06, Jürgen Groß wrote:
On 12.11.19 14:48, Jan Beulich wrote:
On 02.10.2019 13:20, Juergen Gross wrote:
+static int hypfs_add_entry(struct hypfs_dir *parent, struct hypfs_entry *new)
+{
+int ret = -ENOENT;
+struct list_head *l;
+
+
On 13.11.19 14:44, Andrew Cooper wrote:
IOMMUs are owned by DOM_XEN, and with XSA-302, DOM_IO is used for
quarantined domains. Use %pd in the printk to render the system
domains more intelligently.
Before:
(XEN) :00:01.0 - dom 0 - node 0 - MSIs < >
(XEN) :00:00.0 - dom 0 -
On 13.11.19 14:41, Andrew Cooper wrote:
c/s bb038f31168 "AMD/IOMMU: replace INTREMAP_ENTRIES" introduces a call to
intremap_table_entries() in dump_intremap_table() before tbl.ptr is checked
for NULL.
intremap_table_entries() internally uses virt_to_page() which falls over
ASSERT(va >=
On 13.11.2019 14:41, Andrew Cooper wrote:
> c/s bb038f31168 "AMD/IOMMU: replace INTREMAP_ENTRIES" introduces a call to
> intremap_table_entries() in dump_intremap_table() before tbl.ptr is checked
> for NULL.
>
> intremap_table_entries() internally uses virt_to_page() which falls over
>
>
On 13.11.2019 14:44, Andrew Cooper wrote:
> IOMMUs are owned by DOM_XEN, and with XSA-302, DOM_IO is used for
> quarantined domains. Use %pd in the printk to render the system
> domains more intelligently.
>
> Before:
> (XEN) :00:01.0 - dom 0 - node 0 - MSIs < >
> (XEN) :00:00.0
On 12.11.2019 17:45, Jürgen Groß wrote:
> On 12.11.19 15:22, Jan Beulich wrote:
>> On 02.10.2019 13:20, Juergen Gross wrote:
>>> @@ -79,3 +80,11 @@ subdir-$(CONFIG_UBSAN) += ubsan
>>>
>>> subdir-$(CONFIG_NEEDS_LIBELF) += libelf
>>> subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
>>> +
>>>
> -Original Message-
> From: Andrew Cooper
> Sent: 13 November 2019 14:05
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH] domain_create: honour global
> grant/maptrack frame limits...
>
> On 13/11/2019 13:47, Paul Durrant wrote:
> > ...when their
On 12.11.2019 17:06, Jürgen Groß wrote:
> On 12.11.19 14:48, Jan Beulich wrote:
>> On 02.10.2019 13:20, Juergen Gross wrote:
>>> +static int hypfs_add_entry(struct hypfs_dir *parent, struct hypfs_entry
>>> *new)
>>> +{
>>> +int ret = -ENOENT;
>>> +struct list_head *l;
>>> +
>>> +if (
On 13.11.19 14:47, Jan Beulich wrote:
On 13.11.2019 01:15, Boris Ostrovsky wrote:
On 11/11/19 9:46 AM, Jan Beulich wrote:
There's no apparent reason why it can be used on 64-bit only.
Signed-off-by: Jan Beulich
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -285,7 +285,7 @@ config
On 13/11/2019 13:47, Paul Durrant wrote:
> ...when their values are larger than the per-domain configured limits.
>
> Signed-off-by: Paul Durrant
> ---
> After mining through commits it is still unclear to me exactly when Xen
> stopped honouring the global values, but I really think this commit
Looks good:
Reviewed-by: Christoph Hellwig
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Looks good,
Reviewed-by: Christoph Hellwig
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Reviewed-by: Christoph Hellwig
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
> +int mmu_interval_notifier_insert(struct mmu_interval_notifier *mni,
> + struct mm_struct *mm, unsigned long start,
> + unsigned long length,
> + const struct mmu_interval_notifier_ops *ops);
> +int
...when their values are larger than the per-domain configured limits.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Wei Liu
After mining through commits it is
Looks good,
Reviewed-by: Christoph Hellwig
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Sorry, the Cc list got dropped... I'll re-send.
Paul
> -Original Message-
> From: Paul Durrant
> Sent: 13 November 2019 13:47
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul
> Subject: [PATCH] domain_create: honour global grant/maptrack frame
> limits...
>
> ...when their
Commit 1b00c16bdf ("AMD/IOMMU: pre-fill all DTEs right after table
allocation") moved ourselves into a more secure default state, but
didn't take sufficient care to also undo the effects when handing a
previously disabled device back to a(nother) domain. Put the fields
that may have been changed
...when their values are larger than the per-domain configured limits.
Signed-off-by: Paul Durrant
---
After mining through commits it is still unclear to me exactly when Xen
stopped honouring the global values, but I really think this commit should
be back-ported to stable trees as it was a
On 13.11.2019 01:15, Boris Ostrovsky wrote:
> On 11/11/19 9:46 AM, Jan Beulich wrote:
>> There's no apparent reason why it can be used on 64-bit only.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/drivers/xen/Kconfig
>> +++ b/drivers/xen/Kconfig
>> @@ -285,7 +285,7 @@ config XEN_ACPI_PROCESSOR
>>
On 13/11/2019 13:41, Andrew Cooper wrote:
> c/s bb038f31168 "AMD/IOMMU: replace INTREMAP_ENTRIES" introduces a call to
> intremap_table_entries() in dump_intremap_table() before tbl.ptr is checked
> for NULL.
>
> intremap_table_entries() internally uses virt_to_page() which falls over
>
>
On 13.11.2019 01:11, Boris Ostrovsky wrote:
> On 11/11/19 9:46 AM, Jan Beulich wrote:
>> --- a/arch/x86/include/asm/msr-index.h
>> +++ b/arch/x86/include/asm/msr-index.h
>> @@ -393,6 +393,8 @@
>> #define MSR_AMD_PSTATE_DEF_BASE 0xc0010064
>> #define MSR_AMD64_OSVW_ID_LENGTH
IOMMUs are owned by DOM_XEN, and with XSA-302, DOM_IO is used for
quarantined domains. Use %pd in the printk to render the system
domains more intelligently.
Before:
(XEN) :00:01.0 - dom 0 - node 0 - MSIs < >
(XEN) :00:00.0 - dom 0 - node 0 - MSIs < >
(XEN) :80:00.2 -
c/s bb038f31168 "AMD/IOMMU: replace INTREMAP_ENTRIES" introduces a call to
intremap_table_entries() in dump_intremap_table() before tbl.ptr is checked
for NULL.
intremap_table_entries() internally uses virt_to_page() which falls over
ASSERT(va >= XEN_VIRT_START);
in __virt_to_page().
On 13.11.2019 14:22, Andrew Cooper wrote:
> I am not convinced the behaviour is worth changing, and I don't have
> time for this scope creep.
There's no scope creep here at all. All I'm asking for is that you
don't blindly OR in EFER_NX into trampoline_efer, but rather check
that it will be
On 12/11/2019 17:15, Jan Beulich wrote:
> On 12.11.2019 17:09, Andrew Cooper wrote:
>> On 04/11/2019 15:31, Jan Beulich wrote:
>>> On 04.11.2019 16:22, Andrew Cooper wrote:
On 04/11/2019 15:03, Jan Beulich wrote:
> On 04.11.2019 15:59, Andrew Cooper wrote:
>> On 04/11/2019 13:25, Jan
flight 144071 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144071/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 143023
build-amd64-libvirt
flight 144059 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144059/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144035
Tests
flight 144075 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144075/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 8c4330818f6ee70cbf7428a40a28a73df1272d10
baseline version:
xen
flight 144058 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144058/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144025
Tests
78 matches
Mail list logo
