On 11.05.2023 21:16, Stewart Hildebrand wrote:
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -219,7 +219,8 @@ int iommu_dt_domain_init(struct domain *d);
> int iommu_release_dt_devices(struct domain *d);
>
> /*
> - * Helper to add master device to the IOMMU using generic
On 11.05.2023 21:16, Stewart Hildebrand wrote:
> @@ -762,9 +767,20 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
> pdev->domain = NULL;
> goto out;
> }
> +#ifdef CONFIG_HAS_DEVICE_TREE
> +ret = iommu_add_dt_pci_device(pdev);
> +if ( ret < 0 )
>
On 11.05.2023 21:16, Stewart Hildebrand wrote:
> It's not necessary to add/remove/assign/deassign pci phantom functions
> for the ARM SMMU drivers. All associated AXI stream IDs are added during
> the iommu call for the base PCI device/function.
>
> However, the ARM SMMU drivers can cope with the
On 11.05.2023 19:09, Oleksii Kurochko wrote:
> bss clear cycle requires proper alignment of __bss_start.
>
> Signed-off-by: Oleksii Kurochko
Reviewed-by: Jan Beulich
with two remarks, though:
While probably not very important yet for RISC-V (until there is at
least enough functionality to, say
flight 180624 xen-unstable real [real]
flight 180630 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180624/
http://logs.test-lab.xenproject.org/osstest/logs/180630/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
flight 180625 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180625/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 180278
test-amd64-amd64-do
On Fri, 2023-05-12 at 09:45 +0200, Jan Beulich wrote:
> On 11.05.2023 19:09, Oleksii Kurochko wrote:
> > bss clear cycle requires proper alignment of __bss_start.
> >
> > Signed-off-by: Oleksii Kurochko
>
> Reviewed-by: Jan Beulich
> with two remarks, though:
>
> While probably not very import
flight 180629 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180629/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0b37723186ec1525b6caf14b0309fb0ed04084d7
baseline version:
ovmf c08a3a96fd19ac8adc75f
On Thu, May 11, 2023 at 01:20:42PM +0530, Viresh Kumar wrote:
> The libxl_virtio file works for only PV devices and the nodes under the
Well, VirtIO devices are a kind of PV devices, yes, like there's Xen PV
devices. So this explanation doesn't really make much sense.
> frontend path are not used
flight 180631 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180631/
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 Thu, May 11, 2023 at 01:20:43PM +0530, Viresh Kumar wrote:
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index 24ac92718288..0405f6efe62a 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -1619,6 +1619,18 @@ hexadecimal format, without the "0x"
On Tue, May 09, 2023 at 01:21:22PM -0500, Bjorn Helgaas wrote:
> On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> > On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
> > > Provide two new helper macros to iterate over PCI device resources and
> > > convert users.
>
>
Tue, 9 May 2023 13:47:11 +0100 Andrew Cooper :
> Why is this 700, and the others just using regular perms?
> Also, doesn't it want quoting like the other examples too?
It is not clear why there is a single mkdir -m 0700 in the tree.
Most likely it will not give any extra security.
The scripts so
On 12/05/2023 12:18 pm, Olaf Hering wrote:
> Tue, 9 May 2023 13:47:11 +0100 Andrew Cooper :
>
>> Why is this 700, and the others just using regular perms?
>> Also, doesn't it want quoting like the other examples too?
> It is not clear why there is a single mkdir -m 0700 in the tree.
> Most likely i
Fri, 12 May 2023 12:22:08 +0100 Andrew Cooper :
> Does this allow for making any of these files no longer
> preprocessed by ./configure ? (i.e. cease being .in files)
The path to hotplugpath.sh is variable, so each consumer needs to be a .in file.
Olaf
pgpSPFRUGSANB.pgp
Description: Digitale
On a fedora system, if you run `sudo sh install.sh` you break your
system. The installation clobbers /var/run, a symlink to /run.
A subsequent boot fails when /var/run and /run are different since
accesses through /var/run can't find items that now only exist in /run
and vice-versa.
Skip populatin
Tue, 9 May 2023 17:47:33 +0100 Anthony PERARD :
> That change isn't enough. And I'm not convinced that it needs to be
> removed.
You are right, the provided functions must be removed as well.
My build scripts do not run autoreconf, perhaps it is about time to
change that.
> First, AX_CHECK_PTYFU
According to openpty(3) it is required to include to get the
prototypes for openpty() and login_tty(). But this is not what the
function AX_CHECK_PTYFUNCS actually does. It makes no attempt to include
the required header.
The two source files which call openpty() and login_tty() already contain
t
When adding new featureset words, it is convenient to split the work into
several patches. However, GCC 12 spotted that the way we prefer to split the
work results in a real (transient) breakage whereby the policy <-> featureset
helpers perform out-of-bounds accesses on the featureset array.
Fix
flight 180626 qemu-mainline real [real]
flight 180634 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180626/
http://logs.test-lab.xenproject.org/osstest/logs/180634/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
At the moment, even in case of a SMMU being I/O coherent, we clean the
updated PT as a result of not advertising the coherency feature. SMMUv3
coherency feature means that page table walks, accesses to memory
structures and queues are I/O coherent (refer ARM IHI 0070 E.A, 3.15).
Follow the same st
This function does not modify its parameter 'dev' and it is not supposed
to do it. Therefore, constify it.
Signed-off-by: Michal Orzel
---
xen/drivers/passthrough/arm/smmu-v3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c
b/xen/dr
Based on the work done for SMMU v1,v2 by commit:
080dcb781e1bc3bb22f55a9dfdecb830ccbabe88
Michal Orzel (2):
xen/arm: smmuv3: Constify arm_smmu_get_by_dev() parameter
xen/arm: smmuv3: Advertise coherent table walk if supported
xen/drivers/passthrough/arm/smmu-v3.c | 28 +++
flight 180628 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180628/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 180613
test-amd64-amd64-libvirt-vhd 19 guest-sta
flight 180635 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180635/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d3225577123767fd09c91201d27e9c91663ae132
baseline version:
ovmf 0b37723186ec1525b6caf
On 12/05/2023 15:35, Michal Orzel wrote:
This function does not modify its parameter 'dev' and it is not supposed
to do it. Therefore, constify it.
Signed-off-by: Michal Orzel
Reviewed-by: Ayan Kumar Halder
Hi Michal,
On 12/05/2023 15:35, Michal Orzel wrote:
At the moment, even in case of a SMMU being I/O coherent, we clean the
updated PT as a result of not advertising the coherency feature. SMMUv3
coherency feature means that page table walks, accesses to memory
structures and queues are I/O coher
On Fri, May 12, 2023 at 01:56:29PM +0300, Andy Shevchenko wrote:
> On Tue, May 09, 2023 at 01:21:22PM -0500, Bjorn Helgaas wrote:
> > On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> > > On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
> > > > Provide two new helper
flight 180632 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180632/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in
180624 pass in 180632
test-amd64-i38
On 5/12/23 03:25, Jan Beulich wrote:
> On 11.05.2023 21:16, Stewart Hildebrand wrote:
>> @@ -762,9 +767,20 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
>> pdev->domain = NULL;
>> goto out;
>> }
>> +#ifdef CONFIG_HAS_DEVICE_TREE
>> +ret = iommu_add_dt_p
Hi!
This is version 4 of the reworked parallel bringup series. Version 3 can be
found here:
https://lore.kernel.org/lkml/20230508181633.089804...@linutronix.de
This is just a reiteration to address the following details:
1) Address review feedback (Peter Zijlstra)
2) Fix a MIPS related
From: Thomas Gleixner
Make topology_phys_to_logical_pkg_die() static as it's only used in
smpboot.c and fixup the kernel-doc warnings for both functions.
Signed-off-by: Thomas Gleixner
Tested-by: Michael Kelley
---
arch/x86/include/asm/topology.h |3 ---
arch/x86/kernel/smpboot.c |
From: Thomas Gleixner
When TSC is synchronized across sockets then there is no reason to
calibrate the delay for the first CPU which comes up on a socket.
Just reuse the existing calibration value.
This removes 100ms pointlessly wasted time from CPU hotplug per socket.
Signed-off-by: Thomas Gl
From: Thomas Gleixner
No point in keeping them around.
Signed-off-by: Thomas Gleixner
Tested-by: Michael Kelley
---
arch/x86/kernel/smpboot.c |4 ++--
kernel/cpu.c |2 +-
kernel/smp.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
--- a/arch/x8
From: Thomas Gleixner
This was introduced with commit e1c467e69040 ("x86, hotplug: Wake up CPU0
via NMI instead of INIT, SIPI, SIPI") to eventually support physical
hotplug of CPU0:
"We'll change this code in the future to wake up hard offlined CPU0 if
real platform and request are available.
From: Thomas Gleixner
This is used in the SEV play_dead() implementation to re-online CPUs. But
that has nothing to do with CPU0.
Signed-off-by: Thomas Gleixner
Tested-by: Michael Kelley
---
arch/x86/include/asm/cpu.h |2 +-
arch/x86/kernel/callthunks.c |2 +-
arch/x86/kernel/head_3
From: David Woodhouse
There are four logical parts to what native_cpu_up() does on the BSP (or
on the controlling CPU for a later hotplug):
1) Wake the AP by sending the INIT/SIPI/SIPI sequence.
2) Wait for the AP to make it as far as wait_for_master_cpu() which
sets that CPU's bit in cpu
From: Thomas Gleixner
This was introduced together with commit e1c467e69040 ("x86, hotplug: Wake
up CPU0 via NMI instead of INIT, SIPI, SIPI") to eventually support
physical hotplug of CPU0:
"We'll change this code in the future to wake up hard offlined CPU0 if
real platform and request are a
Peter stumbled over the barrier() after the invocation of smp_callin() in
start_secondary():
"...this barrier() and it's comment seem weird vs smp_callin(). That
function ends with an atomic bitop (it has to, at the very least it must
not be weaker than store-release) but also has an expli
From: Thomas Gleixner
Now that the CPU0 hotplug cruft is gone, the only user is AMD SEV.
Signed-off-by: Thomas Gleixner
Tested-by: Michael Kelley
---
arch/x86/kernel/callthunks.c |2 +-
arch/x86/kernel/head_32.S| 14 --
arch/x86/kernel/head_64.S|2 +-
3 files cha
From: Thomas Gleixner
The synchronization of the AP with the control CPU is a SMP boot problem
and has nothing to do with cpu_init().
Open code cpu_init_secondary() in start_secondary() and move
wait_for_master_cpu() into the SMP boot code.
No functional change.
Signed-off-by: Thomas Gleixner
From: Thomas Gleixner
Spin-waiting on the control CPU until the AP reaches the TSC
synchronization is just a waste especially in the case that there is no
synchronization required.
As the synchronization has to run with interrupts disabled the control CPU
part can just be done from a SMP functio
From: Thomas Gleixner
The usage is in smpboot.c and not in the CPU initialization code.
The XEN_PV usage of cpu_callout_mask is obsolete as cpu_init() not longer
waits and cacheinfo has its own CPU mask now, so cpu_callout_mask can be
made static too.
Signed-off-by: Thomas Gleixner
Tested-by:
From: Thomas Gleixner
Now that the core code drops sparse_irq_lock after the idle thread
synchronized, it's pointless to wait for the AP to mark itself online.
Whether the control CPU runs in a wait loop or sleeps in the core code
waiting for the online operation to complete makes no difference.
From: Thomas Gleixner
cpu_callout_mask is used for the stop machine based MTRR/PAT init.
In preparation of moving the BP/AP synchronization to the core hotplug
code, use a private CPU mask for cacheinfo and manage it in the
starting/dying hotplug state.
Signed-off-by: Thomas Gleixner
Tested-by
From: Thomas Gleixner
Now that TSC synchronization is SMP function call based there is no reason
to wait for the AP to be set in smp_callin_mask. The control CPU waits for
the AP to set itself in the online mask anyway.
Signed-off-by: Thomas Gleixner
Tested-by: Michael Kelley
---
V4: Rename sm
From: Thomas Gleixner
There is no harm to hold sparse_irq lock until the upcoming CPU completes
in cpuhp_online_idle(). This allows to remove cpu_online() synchronization
from architecture code.
Signed-off-by: Thomas Gleixner
Tested-by: Michael Kelley
---
V4: Amend comment about sparse irq loc
From: Thomas Gleixner
No point in this conditional voodoo. Un-initializing the lock mechanism is
safe to be called unconditionally even if it was already invoked when the
CPU died.
Remove the invocation of xen_smp_intr_free() as that has been already
cleaned up in xen_cpu_dead_hvm().
Signed-off
From: Thomas Gleixner
The CPU state tracking and synchronization mechanism in smpboot.c is
completely independent of the hotplug code and all logic around it is
implemented in architecture specific code.
Except for the state reporting of the AP there is absolutely nothing
architecture specific a
From: Thomas Gleixner
The new AP state tracking and synchronization mechanism in the CPU hotplug
core code allows to remove quite some x86 specific code:
1) The AP alive synchronization based on cpumasks
2) The decision whether an AP can be brought up again
Signed-off-by: Thomas Gleixner
From: Thomas Gleixner
Now that the core code drops sparse_irq_lock after the idle thread
synchronized, it's pointless to wait for the AP to mark itself online.
Signed-off-by: Thomas Gleixner
Tested-by: Michael Kelley
---
arch/x86/kernel/smpboot.c | 26 ++
1 file chan
On Wed, 10 May 2023, Olaf Hering wrote:
> Wed, 10 May 2023 00:58:27 +0200 Olaf Hering :
>
> > In my debugging (with v8.0.0) it turned out the three pci_set_word
> > causes the domU to hang. In fact, it is just the last one:
> >
> >pci_set_byte(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */
> >
From: Thomas Gleixner
Switch to the CPU hotplug core state tracking and synchronization
mechanim. No functional change intended.
Signed-off-by: Thomas Gleixner
Tested-by: Michael Kelley
Acked-by: Palmer Dabbelt
---
arch/riscv/Kconfig |1 +
arch/riscv/include/asm/smp.h|
From: Thomas Gleixner
Switch to the CPU hotplug core state tracking and synchronization
mechanim. No functional change intended.
Signed-off-by: Thomas Gleixner
Tested-by: Mark Rutland
Tested-by: Michael Kelley
---
arch/arm64/Kconfig |1 +
arch/arm64/include/asm/smp.h |2 +-
From: Thomas Gleixner
Parallel AP bringup requires that the APs can run fully parallel through
the early startup code including the real mode trampoline.
To prepare for this implement a bit-spinlock to serialize access to the
real mode stack so that parallel upcoming APs are not going to corrupt
From: Thomas Gleixner
The bring up logic of a to be onlined CPU consists of several parts, which
are considered to be a single hotplug state:
1) Control CPU issues the wake-up
2) To be onlined CPU starts up, does the minimal initialization,
reports to be alive and waits for release int
From: David Woodhouse
In parallel startup mode the APs are kicked alive by the control CPU
quickly after each other and run through the early startup code in
parallel. The real-mode startup code is already serialized with a
bit-spinlock to protect the real-mode stack.
In parallel startup mode th
From: Thomas Gleixner
Switch to the CPU hotplug core state tracking and synchronization
mechanim. No functional change intended.
Signed-off-by: Thomas Gleixner
Tested-by: Michael Kelley
---
arch/csky/Kconfig |1 +
arch/csky/include/asm/smp.h |2 +-
arch/csky/kernel/smp.c
From: Thomas Gleixner
Implement the validation function which tells the core code whether
parallel bringup is possible.
The only condition for now is that the kernel does not run in an encrypted
guest as these will trap the RDMSR via #VC, which cannot be handled at that
point in early startup.
From: Thomas Gleixner
Make the primary thread tracking CPU mask based in preparation for simpler
handling of parallel bootup.
Signed-off-by: Thomas Gleixner
Tested-by: Michael Kelley
---
arch/x86/include/asm/apic.h |2 --
arch/x86/include/asm/topology.h | 19 +++
arc
From: Thomas Gleixner
No more users.
Signed-off-by: Thomas Gleixner
Tested-by: Michael Kelley
---
include/linux/cpu.h |2 -
kernel/smpboot.c| 90
2 files changed, 92 deletions(-)
--- a/include/linux/cpu.h
+++ b/include/linux/cpu
From: Thomas Gleixner
Switch to the CPU hotplug core state tracking and synchronization
mechanim. This unfortunately requires to add dead reporting to the non CPS
platforms as CPS is the only user, but it allows an overall consolidation
of this functionality.
No functional change intended.
Sign
From: Thomas Gleixner
All users converted to the hotplug core mechanism.
Signed-off-by: Thomas Gleixner
Tested-by: Michael Kelley
---
include/linux/cpu.h |2 -
kernel/smpboot.c| 75
2 files changed, 77 deletions(-)
--- a/include
From: Thomas Gleixner
Switch to the CPU hotplug core state tracking and synchronization
mechanim. No functional change intended.
Signed-off-by: Thomas Gleixner
Tested-by: Michael Kelley
---
arch/parisc/Kconfig |1 +
arch/parisc/kernel/process.c |4 ++--
arch/parisc/kernel/smp
From: Thomas Gleixner
There is often significant latency in the early stages of CPU bringup, and
time is wasted by waking each CPU (e.g. with SIPI/INIT/INIT on x86) and
then waiting for it to respond before moving on to the next.
Allow a platform to enable parallel setup which brings all to be o
From: David Woodhouse
Commit dce1ca0525bf ("sched/scs: Reset task stack state in bringup_cpu()")
ensured that the shadow call stack and KASAN poisoning were removed from
a CPU's stack each time that CPU is brought up, not just once.
This is not incorrect. However, with parallel bringup the idle
From: Thomas Gleixner
Switch to the CPU hotplug core state tracking and synchronization
mechanim. No functional change intended.
Signed-off-by: Thomas Gleixner
Tested-by: Michael Kelley
---
arch/arm/Kconfig |1 +
arch/arm/include/asm/smp.h |2 +-
arch/arm/kernel/smp.c |
From: Thomas Gleixner
For parallel CPU brinugp it's required to read the APIC ID in the low level
startup code. The virtual APIC base address is a constant because its a
fix-mapped address. Exposing that constant which is composed via macros to
assembly code is non-trivial due to header inclusion
From: Thomas Gleixner
The x86 CPU bringup state currently does AP wake-up, wait for AP to
respond and then release it for full bringup.
It is safe to be split into a wake-up and and a separate wait+release
state.
Provide the required functions and enable the split CPU bringup, which
prepares fo
>From tools/libs/light/libxl_x86.c: libxl__arch_passthrough_mode_setdefault()
"passthrough not yet supported for x86 PVH guests\n"
So PVH is recommended for most situations, but it is /still/ impossible
to pass hardware devices to PVH domains? Seems odd this has never been
addressed with how lon
Hi all,
These 2 patches are necessary to boot Xen and Dom0 PVH on QEMU (with or
without KVM acceleration.)
The first one is a genuine fix. The second one is a workaround: I don't
know the underlying root cause of the problem.
Cheers,
Stefano
From: Stefano Stabellini
Mapping the ACPI tables to Dom0 PVH 1:1 leads to memory corruptions of
the tables in the guest. Instead, copy the tables to Dom0.
This is a workaround.
Signed-off-by: Stefano Stabellini
---
As mentioned in the cover letter, this is a RFC workaround as I don't
know the
From: Stefano Stabellini
Xen always generates a XSDT table even if the firmware provided a RSDT
table. Instead of copying the XSDT header from the firmware table (that
might be missing), generate the XSDT header from a preset.
Signed-off-by: Stefano Stabellini
---
xen/arch/x86/hvm/dom0_build.c
From: Stefano Stabellini
Straightforward Dom0 PVH test based on the existing basic Smoke test for
the Qubes runner.
Signed-off-by: Stefano Stabellini
---
automation/gitlab-ci/test.yaml | 8
automation/scripts/qubes-x86-64.sh | 14 +-
2 files changed, 17 insertions(+),
flight 180633 linux-linus real [real]
flight 180640 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180633/
http://logs.test-lab.xenproject.org/osstest/logs/180640/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
On Fri, May 12, 2023 at 06:28:33PM -0700, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Straightforward Dom0 PVH test based on the existing basic Smoke test for
> the Qubes runner.
>
> Signed-off-by: Stefano Stabellini
> ---
> automation/gitlab-ci/test.yaml | 8
> auto
The PV passthrough test currently fails on this system
with:
(d1) Can't find new memory area for initrd needed due to E820 map conflict
Setting e820_host=1 does not help. So, add this test with
"allow_failure: true" until the problem is fixed.
Signed-off-by: Marek Marczykowski-Górecki
---
I'm un
This makes the test script easier reusable for different runners, where
console may be connected differently. Include both console= option and
configuration for specific chosen console too (like com1= here) in the
'CONSOLE_OPTS' variable.
Signed-off-by: Marek Marczykowski-Górecki
---
This will co
This series adds another hardware runner to the CI.
See individual patch descriptions for details.
Marek Marczykowski-Górecki (4):
automation: make console options configurable via variables
automation: enable earlyprintk=xen for both dom0 and domU in hw tests
automation: add x86_64 tests on
This adds another physical runner to Gitlab-CI, running similar set of
jobs that the Adler Lake one.
The machine specifically is
MinisForum UM773 Lite with AMD Ryzen 7 7735HS
The PV passthrough test is skipped as currently it fails on this system
with:
(d1) Can't find new memory area for initrd n
Make debugging early boot failures easier based on just CI logs.
Signed-off-by: Marek Marczykowski-Górecki
---
automation/scripts/qubes-x86-64.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/automation/scripts/qubes-x86-64.sh
b/automation/scripts/qubes-x86-64.sh
index
flight 180637 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180637/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 180610
test-amd64-amd64-xl-qemuu-ws16-amd6
82 matches
Mail list logo
