flight 171676 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171676/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 171648
test-armhf-armhf-libvirt 16 sav
> From: Roger Pau Monne
> Sent: Friday, July 1, 2022 9:17 PM
>
> @@ -4065,6 +4065,11 @@ void vmx_vmexit_handler(struct cpu_user_regs
> *regs)
>
> if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) )
> return vmx_failed_vmentry(exit_reason, regs);
Add a blank line.
> +
> From: Roger Pau Monné
> Sent: Monday, July 4, 2022 6:07 PM
>
> On Mon, Jul 04, 2022 at 11:27:37AM +0200, Jan Beulich wrote:
> > On 01.07.2022 15:16, Roger Pau Monne wrote:
> > > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > > @@ -4065,6 +4065,11 @@ void vmx_vmexit_
> From: Roger Pau Monne
> Sent: Friday, July 1, 2022 9:17 PM
>
> @@ -225,6 +225,9 @@ static inline void pi_clear_sn(struct pi_desc *pi_desc)
>
> /*
> * Interruption-information format
> + *
> + * Note INTR_INFO_NMI_UNBLOCKED_BY_IRET is also used with Exit
> Qualification
> + * field under som
Hi Christopher,
> On 19 Jul 2022, at 05:34, Christopher Clark
> wrote:
>
> On Thu, Jul 14, 2022 at 3:10 AM Bertrand Marquis
> wrote:
>>
>> This patch series is a first attempt to check if we could use Yocto in
>> gitlab ci to build and run xen on qemu for arm, arm64 and x86.
>
> Hi Bertrand,
Hi Jan,
On 19/07/2022 06:58, Jan Beulich wrote:
On 18.07.2022 18:28, Julien Grall wrote:
On 18/07/2022 17:12, Jan Beulich wrote:
On 27.05.2022 09:24, Juergen Gross wrote:
As you committed, I would be OK if this is addressed in a follow-up
series. But this *must* be addressed by the time 4.17
> From: Roger Pau Monne
> Sent: Friday, July 1, 2022 9:17 PM
> @@ -4589,6 +4601,22 @@ void vmx_vmexit_handler(struct cpu_user_regs
> *regs)
> */
> break;
>
> +case EXIT_REASON_NOTIFY:
> +__vmread(EXIT_QUALIFICATION, &exit_qualification);
> +
> +if ( exit_qua
On 06.07.2022 23:04, Daniel P. Smith wrote:
> --- a/xen/arch/Kconfig
> +++ b/xen/arch/Kconfig
> @@ -17,3 +17,15 @@ config NR_CPUS
> For CPU cores which support Simultaneous Multi-Threading or similar
> technologies, this the number of logical threads which Xen will
> support
On 06.07.2022 23:04, Daniel P. Smith wrote:
> This refactors reusable code from Arm's bootfdt.c and device-tree.h that is
> general fdt handling code. The Kconfig parameter CORE_DEVICE_TREE is
> introduced for when the ability of parsing DTB files is needed by a capability
> such as hyperlaunch.
>
flight 171682 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171682/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hello Jan,
Jan Beulich writes:
> On 18.07.2022 23:15, Volodymyr Babchuk wrote:
>> Patch b4f211606011 ("vpci/msix: fix PBA accesses") introduced call to
>> iounmap(), but not added corresponding include.
>>
>> Fixes: b4f211606011 ("vpci/msix: fix PBA accesses")
>
> I don't think there's any ac
On 19.07.2022 12:32, Volodymyr Babchuk wrote:
> Jan Beulich writes:
>
>> On 18.07.2022 23:15, Volodymyr Babchuk wrote:
>>> Patch b4f211606011 ("vpci/msix: fix PBA accesses") introduced call to
>>> iounmap(), but not added corresponding include.
>>>
>>> Fixes: b4f211606011 ("vpci/msix: fix PBA acc
flight 171678 xen-unstable real [real]
flight 171684 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171678/
http://logs.test-lab.xenproject.org/osstest/logs/171684/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
flight 171680 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171680/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
Henry,
Forwarded Message
Subject: Ping²: [PATCH] x86: enable interrupts around dump_execstate()
Date: Tue, 5 Jul 2022 18:19:38 +0200
From: Jan Beulich
To: Andrew Cooper , Roger Pau Monné
CC: Wei Liu , xen-devel@lists.xenproject.org
>On 11.01.2022 11:08, Jan Beulich wrote:
>
On 16/12/2021 13:33, Jan Beulich wrote:
> On 16.12.2021 12:54, Andrew Cooper wrote:
>> On 13/12/2021 15:12, Jan Beulich wrote:
>>> show_hvm_stack() requires interrupts to be enabled to avoids triggering
>>> the consistency check in check_lock() for the p2m lock. To do so in
>>> spurious_interrupt()
On 19.07.2022 13:22, Andrew Cooper wrote:
> On 16/12/2021 13:33, Jan Beulich wrote:
>> On 16.12.2021 12:54, Andrew Cooper wrote:
>>> On 13/12/2021 15:12, Jan Beulich wrote:
show_hvm_stack() requires interrupts to be enabled to avoids triggering
the consistency check in check_lock() for th
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Henry,
>
> Forwarded Message
> Subject: Ping²: [PATCH] x86: enable interrupts around dump_execstate()
>
> >On 11.01.2022 11:08, Jan Beulich wrote:
> >> On 16.12.2021 14:33, Jan Beulich wrote:
> >>> On 16.12.2021 12:54,
Since both kernel and user mode run in ring 3, they run in the same
"predictor mode". While the kernel could take care of this itself, doing
so would be yet another item distinguishing PV from native. Additionally
we're in a much better position to issue the barrier command, and we can
save a #GP (
Already ISE rev 044 added text to this effect; rev 045 further dropped
leftover earlier text indicating the contrary:
- ENQCMD requires the low 32 bits of the memory operand to be clear,
- ENDCMDS requires bits 20...30 of the memory operand to be clear.
Signed-off-by: Jan Beulich
---
I'm a little
On 06.07.2022 23:04, Daniel P. Smith wrote:
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/bootinfo.h
> @@ -0,0 +1,48 @@
> +#ifndef __ARCH_X86_BOOTINFO_H__
> +#define __ARCH_X86_BOOTINFO_H__
> +
> +/* unused for x86 */
> +struct arch_bootstring { };
> +
> +struct __packed arch_bootmodule {
> +#de
On 7/18/2022 7:32 AM, Chuck Zmudzinski wrote:
> On 7/17/2022 3:55 AM, Thorsten Leemhuis wrote:
> > Hi Juergen!
> >
> > On 15.07.22 16:25, Juergen Gross wrote:
> > > Today PAT can't be used without MTRR being available, unless MTRR is at
> > > least configured via CONFIG_MTRR and the system is runni
On 06.07.2022 23:04, Daniel P. Smith wrote:
> This commit replaces the use of the multiboot v1 structures starting
> at __start_xen(). The majority of this commit is converting the fields
> being accessed for the startup calculations. While adapting the ucode
> boot module location logic, this code
On 06.07.2022 23:04, Daniel P. Smith wrote:
> --- a/xen/include/xen/bootinfo.h
> +++ b/xen/include/xen/bootinfo.h
> @@ -53,6 +53,17 @@ struct __packed boot_info {
>
> extern struct boot_info *boot_info;
>
> +static inline char *bootinfo_prepare_cmdline(struct boot_info *bi)
> +{
> +bi->cmd
On 06.07.2022 23:04, Daniel P. Smith wrote:
> --- /dev/null
> +++ b/xen/common/domain-builder/Kconfig
> @@ -0,0 +1,15 @@
> +
> +menu "Domain Builder Features"
> +
> +config BUILDER_FDT
> + bool "Domain builder device tree (UNSUPPORTED)" if UNSUPPORTED
> + select CORE_DEVICE_TREE
> + ---
From: Anthony PERARD
The macro "xen_mb()" needs to be a full memory barrier, that is it
needs to also prevent stores from been reorder after loads which an
x86 CPU can do (as I understand from reading [1]). So this patch makes
use of "mfence" instruction.
Currently, there's a good chance that Ov
On 19/07/2022 14:52, Anthony Perard wrote:
> diff --git a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
> b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
> index 350b7bd309c0..67ee1899e9a8 100644
> --- a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
> +++ b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
> @@ -11,8 +11,9 @@
> #define __EFI_XEN_P
On 7/14/2022 6:45 PM, Chuck Zmudzinski wrote:
> On 7/14/2022 6:33 PM, Chuck Zmudzinski wrote:
> > On 7/14/2022 1:17 PM, Chuck Zmudzinski wrote:
> > > On 7/5/22 6:57 AM, Thorsten Leemhuis wrote:
> > > > [CCing tglx, mingo, Boris and Juergen]
> > > >
> > > > On 04.07.22 14:26, Jan Beulich wrote:
> >
flight 171685 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171685/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Fri, Jul 15, 2022 at 04:25:49PM +0200, Juergen Gross wrote:
> Today PAT is usable only with MTRR being active, with some nasty tweaks
> to make PAT usable when running as Xen PV guest, which doesn't support
> MTRR.
>
> The reason for this coupling is, that both, PAT MSR changes and MTRR
> chang
On 7/15/22 15:16, Julien Grall wrote:
> Hi Daniel,
>
> On 06/07/2022 22:04, Daniel P. Smith wrote:
>> For x86 the number of allowable multiboot modules varies between the
>> different
>> entry points, non-efi boot, pvh boot, and efi boot. In the case of
>> both Arm and
>> x86 this value is fixed
flight 171681 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171681/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 171664
Tests which did not succeed,
On 7/19/22 05:32, Jan Beulich wrote:
> On 06.07.2022 23:04, Daniel P. Smith wrote:
>> --- a/xen/arch/Kconfig
>> +++ b/xen/arch/Kconfig
>> @@ -17,3 +17,15 @@ config NR_CPUS
>>For CPU cores which support Simultaneous Multi-Threading or similar
>>technologies, this the number of logica
Hi Daniel,
> -Original Message-
> Subject: [PATCH v1 00/18] Hyperlaunch
With the adjustments that I suggested in other messages, this patch builds and
boots for me on x86 (including a device tree with a domU). I will continue to
poke around and see if I discover any other rough edges.
Currently the vPMU state from a parent isn't copied to VM forks. To enable the
vPMU state to be copied to a fork VM we export certain vPMU functions. First,
the vPMU context needs to be allocated for the fork if the parent has one. For
this we introduce vpmu->allocate_context, which has previously
From: Oleksandr Andrushchenko
Add a stub for is_memory_hole which is required for PCI passthrough
on Arm.
Signed-off-by: Oleksandr Andrushchenko
---
OT: It looks like the discussion got stuck. As I understand this
patch is not immediately needed in the context of current series
as PCI passthrou
From: Oleksandr Andrushchenko
Add relevant vpci register handlers when assigning PCI device to a domain
and remove those when de-assigning. This allows having different
handlers for different domains, e.g. hwdom and other guests.
Emulate guest BAR register values: this allows creating a guest vi
From: Oleksandr Andrushchenko
There are range sets which should not be printed, so introduce a flag
which allows marking those as such. Implement relevant logic to skip
such entries while printing.
While at it also simplify the definition of the flags by directly
defining those without helpers.
From: Oleksandr Andrushchenko
When a PCI device gets assigned/de-assigned some work on vPCI side needs
to be done for that device. Introduce a pair of hooks so vPCI can handle
that.
Signed-off-by: Oleksandr Andrushchenko
---
Since v6:
- do not pass struct domain to vpci_{assign|deassign}_device
From: Oleksandr Andrushchenko
Instead of handling a single range set, that contains all the memory
regions of all the BARs and ROM, have them per BAR.
As the range sets are now created when a PCI device is added and destroyed
when it is removed so make them named and accounted.
Note that rangese
From: Oleksandr Tyshchenko
Hi, all!
You can find previous discussion at [1].
1. This patch series is focusing on vPCI and adds support for non-identity
PCI BAR mappings which is required while passing through a PCI device to
a guest. The highlights are:
- Add relevant vpci register handlers wh
From: Oleksandr Andrushchenko
Reset the command register when assigning a PCI device to a guest:
according to the PCI spec the PCI_COMMAND register is typically all 0's
after reset, but this might not be true for the guest as it needs
to respect host's settings.
For that reason, do not write 0 to
From: Oleksandr Andrushchenko
Xen and/or Dom0 may have put values in PCI_COMMAND which they expect
to remain unaltered. PCI_COMMAND_SERR bit is a good example: while the
guest's view of this will want to be zero initially, the host having set
it to 1 may not easily be overwritten with 0, or else
From: Oleksandr Andrushchenko
At the moment, we always allocate an extra 16 slots for IO handlers
(see MAX_IO_HANDLER). So while adding IO trap handlers for the emulated
MSI-X registers we need to explicitly tell that we have additional IO
handlers, so those are accounted.
Signed-off-by: Oleksan
From: Oleksandr Andrushchenko
There are three originators for the PCI configuration space access:
1. The domain that owns physical host bridge: MMIO handlers are
there so we can update vPCI register handlers with the values
written by the hardware domain, e.g. physical view of the registers
vs g
From: Oleksandr Andrushchenko
Assign SBDF to the PCI devices being passed through with bus 0.
The resulting topology is where PCIe devices reside on the bus 0 of the
root complex itself (embedded endpoints).
This implementation is limited to 32 devices which are allowed on
a single PCI bus.
Plea
From: Oleksandr Andrushchenko
Take into account guest's BAR view and program its p2m accordingly:
gfn is guest's view of the BAR and mfn is the physical BAR value as set
up by the PCI bus driver in the hardware domain.
This way hardware domain sees physical BAR values and guest sees
emulated ones
flight 171688 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171688/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 171687 seabios real [real]
flight 171690 seabios real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171687/
http://logs.test-lab.xenproject.org/osstest/logs/171690/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl
On Tue, Jul 19, 2022 at 2:23 PM Andrew Cooper wrote:
>
> On 19/07/2022 18:18, Tamas K Lengyel wrote:
> > diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
> > index d2c03a1104..2b5d64a60d 100644
> > --- a/xen/arch/x86/cpu/vpmu.c
> > +++ b/xen/arch/x86/cpu/vpmu.c
> > @@ -529,6 +529,16
flight 171689 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171689/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 19a87683654a4969a9f86a3d02199c253c789970
baseline version:
ovmf f0064ac3afa28e1aa3b6b
Hi Dan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on xen-tip/linux-next]
[also build test WARNING on linus/master v5.19-rc7 next-20220719]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
commit e46474278a0e ("x86/intel: Expose MSR_ARCH_CAPS to dom0") started
exposing MSR_ARCH_CAPS to dom0. More bits in MSR_ARCH_CAPS have since
been defined, but they haven't been exposed. Update the list to allow
them through.
As one example, this allows a linux Dom0 to know that it has the
appro
On 19/07/2022 13:56, Jan Beulich wrote:
> Already ISE rev 044 added text to this effect; rev 045 further dropped
> leftover earlier text indicating the contrary:
> - ENQCMD requires the low 32 bits of the memory operand to be clear,
> - ENDCMDS requires bits 20...30 of the memory operand to be clea
On 19/07/2022 21:08, Jason Andryuk wrote:
> commit e46474278a0e ("x86/intel: Expose MSR_ARCH_CAPS to dom0") started
> exposing MSR_ARCH_CAPS to dom0. More bits in MSR_ARCH_CAPS have since
> been defined, but they haven't been exposed. Update the list to allow
> them through.
>
> As one example, t
flight 171683 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171683/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 14 guest-start fail REGR. vs. 171676
Tests which did not succee
flight 171691 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171691/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 671b0cea510ad6de02ee9d6dbdf8f9bbb881f35d
baseline version:
ovmf 19a87683654a4969a9f86
flight 171686 xen-unstable real [real]
flight 171692 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171686/
http://logs.test-lab.xenproject.org/osstest/logs/171692/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
> I'd focus on the booting issues first. And I guess you can take a video
> of that (assuming that a single screenshot likely isn't going to be
> enough), possibly with "vga=keep" in place (albeit that introduces
> extra slowness)?
>
> There's also the option of using an EHCI debug port for the ser
From: Peter Zijlstra
[ Upstream commit 9bb2ec608a209018080ca262f771e6a9ff203b6f ]
Update retpoline validation with the new CONFIG_RETPOLINE requirement of
not having bare naked RET instructions.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
Reviewed-by: Josh Poimboeuf
From: Peter Zijlstra
[ Upstream commit b75b7f8ef1148be1b9321ffc2f6c19238904b438 ]
Native SYS{CALL,ENTER} entry points are called
entry_SYS{CALL,ENTER}_{64,compat}, make sure the Xen versions are
named consistently.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
Reviewed-
On 7/15/22 10:25 AM, Juergen Gross wrote:
> Today PAT is usable only with MTRR being active, with some nasty tweaks
> to make PAT usable when running as Xen PV guest, which doesn't support
> MTRR.
>
> The reason for this coupling is, that both, PAT MSR changes and MTRR
> changes, require a similar
From: Peter Zijlstra
[ Upstream commit b75b7f8ef1148be1b9321ffc2f6c19238904b438 ]
Native SYS{CALL,ENTER} entry points are called
entry_SYS{CALL,ENTER}_{64,compat}, make sure the Xen versions are
named consistently.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
Reviewed-
Hi Oleksandr,
We have tested it on arm64 with " disk = [ 'phy:/usr/share/guests/disk.img0,
xvda1, backendtype=standalone, specification=virtio']". It works ok.
Tested-by: Jiamei Xie
Tested-by: Henry Wang
Best wishes
Jiamei Xie
> -Original Message-
> From: Xen-devel On Behalf Of
> O
So, you think it's a problem with fc36?
Original message From: Andrew Cooper
Date: 7/18/22 6:25 PM (GMT-05:00) To:
ch...@dalessio.org, xen-devel@lists.xenproject.org Cc: Jan Beulich
, Michael Young Subject: Re: Panic
on CPU 0: FATAL TRAP: vec 7, #NM[] On 18/07/2022 22:3
flight 171693 qemu-mainline real [real]
flight 171698 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171693/
http://logs.test-lab.xenproject.org/osstest/logs/171698/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
Today when a domain unpopulates the memory on runtime, they will always
hand the memory over to the heap allocator. And it will be a problem if it
is a static domain.
Pages used as guest RAM for static domain shall always be reserved to this
domain only, and not be used for any other purposes, so t
PGC_reserved could be ambiguous, and we have to tell what the pages are
reserved for, so this commit intends to rename PGC_reserved to
PGC_static, which clearly indicates the page is reserved for static
memory.
Signed-off-by: Penny Zheng
Acked-by: Jan Beulich
Acked-by: Julien Grall
---
v8 chang
The code in free_heap_pages() will try to merge pages with the
successor/predecessor if pages are suitably aligned. So if the pages
reserved are right next to the pages given to the heap allocator,
free_heap_pages() will merge them, and give the reserved pages to heap
allocator accidently as a resu
Pages used as guest RAM for static domain, shall be reserved to this
domain only.
So in case reserved pages being used for other purpose, users
shall not free them back to heap, even when last ref gets dropped.
This commit introduces a new helper free_domstatic_page to free
static page in runtime,
With more and more CDF_xxx internal flags in and to save the space, this
commit introduces a new field "flags" in struct domain to store CDF_*
internal flags directly.
Another new CDF_xxx will be introduced in the next patch.
Signed-off-by: Penny Zheng
Acked-by: Julien Grall
---
v9 changes:
- n
In order to have an easy and quick way to find out whether this domain memory
is statically configured, this commit introduces a new flag CDF_staticmem and a
new helper is_domain_using_staticmem() to tell.
Signed-off-by: Penny Zheng
Acked-by: Julien Grall
Acked-by: Jan Beulich
---
v9 changes:
-
Today when a domain unpopulates the memory on runtime, they will always
hand the memory back to the heap allocator. And it will be a problem if domain
is static.
Pages as guest RAM for static domain shall be reserved to only this domain
and not be used for any other purposes, so they shall never g
Later, we want to use acquire_domstatic_pages() for populating memory
for static domain on runtime, however, there are a lot of pointless work
(checking mfn_valid(), scrubbing the free part, cleaning the cache...)
considering we know the page is valid and belong to the guest.
This commit splits ac
When a static domain populates memory through populate_physmap at runtime,
it shall retrieve reserved pages from resv_page_list to make sure that
guest RAM is still restricted in statically configured memory regions.
This commit also introduces a new helper acquire_reserved_page to make it work.
S
flight 171695 xen-unstable real [real]
flight 171701 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171695/
http://logs.test-lab.xenproject.org/osstest/logs/171701/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
flight 171700 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171700/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
77 matches
Mail list logo
