> On 15 Jun 2023, at 22:27, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> Also add a comment at the top of the file to say rules.rst could be
> changed.
>
> Signed-off-by: Stefano Stabellini
Hi Stefano,
Reviewed-by: Luca Fancellu
While I was testing the patch with our scri
On 15.06.2023 18:39, nicola wrote:
> while investigating possible patches regarding Mandatory Rule 9.1, I
> found the following pattern, that is likely to results in a lot possible
> positives from many (all) static analysis tools for this rule.
>
> This is the current status (taken from `xen/comm
On 16/06/23 08:53, Jan Beulich wrote:
On 16.06.2023 01:26, Stefano Stabellini wrote:
On Thu, 15 Jun 2023, Roberto Bagnara wrote:
I have a few comments below, mostly to clarify the description of some
of the less documented GCC extensions, for the purpose of having all
community members be able t
Hi Julien,
On 15/06/2023 22:32, Julien Grall wrote:
>
>
> Hi Michal,
>
> I notice you posted some comments but didn't add a Acked-by/Reviewed-by.
> Can you indicate if you are happy with the patch so long your comments
> are addressed?
>
> If so, are you OK if I deal with them on commit?
I tho
On 16/06/23 09:19, Jan Beulich wrote:
On 15.06.2023 18:39, nicola wrote:
while investigating possible patches regarding Mandatory Rule 9.1, I
found the following pattern, that is likely to results in a lot possible
positives from many (all) static analysis tools for this rule.
This is the cu
Wed, 14 Jun 2023 11:49:35 +0200 Jan Beulich :
> However, if you're after adding packed attributes, and if you're
> meaning to only communicate between Xen and the tool stack, then
> the requirement above doesn't exist. Yet then I would also wonder
> whether you need any compat translation in the f
On 16.06.2023 09:45, Roberto Bagnara wrote:
> On 16/06/23 08:53, Jan Beulich wrote:
>> On 16.06.2023 01:26, Stefano Stabellini wrote:
>> Another is that it's
>> hard to tell how to convince oneself of this being an exhaustive
>> enumeration. One extension we use extensively yet iirc is missing here
On 16.06.2023 11:51, Olaf Hering wrote:
> Wed, 14 Jun 2023 11:49:35 +0200 Jan Beulich :
>
>> However, if you're after adding packed attributes, and if you're
>> meaning to only communicate between Xen and the tool stack, then
>> the requirement above doesn't exist. Yet then I would also wonder
>>
Fri, 16 Jun 2023 12:07:20 +0200 Jan Beulich :
> ... you're removing the line that's actually verifying this is the case.
Yeah, because it disappeared. I think the other approach is to teach
the python tool about __attribute__(()).
Let me know which way is preferred.
Olaf
pgpghOyGFRHEO.pgp
De
Update to OVMF's latest stable tag.
This is been prompt by trying to build Xen on Debian Bookworm,
where edk2-stable202108 doesn't build. Also, it's been too long since
the last update.
Signed-off-by: Anthony PERARD
---
I've tested it in osstest, so the update should be fine:
http://logs.test-l
flight 181456 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181456/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 6 kernel-build fail REGR. vs. 180278
build-armhf-pvops
On 16.06.2023 12:22, Olaf Hering wrote:
> Fri, 16 Jun 2023 12:07:20 +0200 Jan Beulich :
>
>> ... you're removing the line that's actually verifying this is the case.
>
> Yeah, because it disappeared. I think the other approach is to teach
> the python tool about __attribute__(()).
>
> Let me kno
On 16.06.2023 12:29, Anthony PERARD wrote:
> Update to OVMF's latest stable tag.
>
> This is been prompt by trying to build Xen on Debian Bookworm,
> where edk2-stable202108 doesn't build. Also, it's been too long since
> the last update.
Hmm, yes, almost 2 years.
> Signed-off-by: Anthony PERARD
Wed, 31 May 2023 11:05:52 +0200 Jan Beulich :
> As said before, num_online_cpus() will under-report for the purpose
> here, as CPUs may have been brought offline, and may be brought online
> again later (independent of the use of "maxcpus=").
It turned out, commit 74584a367051bc0d6f4b96fd360fa7bc
On 16.06.2023 13:47, Olaf Hering wrote:
> Wed, 31 May 2023 11:05:52 +0200 Jan Beulich :
>
>> As said before, num_online_cpus() will under-report for the purpose
>> here, as CPUs may have been brought offline, and may be brought online
>> again later (independent of the use of "maxcpus=").
>
> It
On 15.06.2023 20:17, Andrew Cooper wrote:
> On 15/06/2023 1:13 pm, Jan Beulich wrote:
>> On 15.06.2023 12:41, Andrew Cooper wrote:
>>> On 15/06/2023 9:30 am, Jan Beulich wrote:
On 14.06.2023 20:12, Andrew Cooper wrote:
> On 13/06/2023 10:59 am, Jan Beulich wrote:
>> On 12.06.2023 18:13
Only %LV should continue on to S handling; avoid emitting a stray 'l'
(typically) in suffix-always mode.
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -11067,19 +11067,20 @@ putop (instr_info *ins, const char *in_t
*ins->obufp++ = ' ';
break;
On 16.06.2023 14:33, Jan Beulich wrote:
> Only %LV should continue on to S handling; avoid emitting a stray 'l'
> (typically) in suffix-always mode.
Oops, I'm sorry, confusion of mailing lists.
Jan
On Mon, Jun 12, 2023 at 02:03:53PM -0700, Vishal Moola (Oracle) wrote:
> Currently, page table information is stored within struct page. As part
> of simplifying struct page, create struct ptdesc for page table
> information.
>
> Signed-off-by: Vishal Moola (Oracle)
> ---
> include/linux/pgtable
The single caller of next_record already checked for
tb_init_done. The functions are called with t_lock
held. The call stack look like this:
__trace_var
tb_init_done?
insert_wrap_record
insert_lost_records
__insert_record
next_record
tb_init_done?
Signed-off-by: Olaf Herin
Hello,
The following series adds support for handling guest MSR features as
defined in arch-x86/cpufeatureset.h.
The end result is the user being able to use such features with the
xl.cfg(5) cpuid option. This also involves adding support to all the
underlying layers, so both libxl and libxc als
Introduce a helper based on the current Xen guest_cpuid code in order
to fetch a cpuid leaf from a policy. The newly introduced function in
cpuid.c should not be directly called and instead the provided
x86_cpuid_get_leaf macro should be used that will properly deal with
const and non-const inputs.
Introduce a local xc_cpu_policy_t and use it to simplify some of the
logic in the function:
* Populate the introduced xc_cpu_policy_t with the current domain
policy, which will already be the default for the given domain
type. This avoids fetching and processing any default policy.
* Use
Introduce an interface that returns a specific leaf/subleaf from a cpu
policy in xen_cpuid_leaf_t format.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
-
Use such helper in order to replace the code in
x86_msr_copy_from_buffer. Note the introduced helper should not be
directly called and instead x86_msr_get_entry should be used that will
properly deal with const and non-const inputs.
Note this requires making the raw fields uint64_t so that it can
Introduce an interface that returns a specific MSR entry from a cpu
policy in xen_msr_entry_t format.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
C
Further changes to the function will require a host policy, hence
switch usages now in order to avoid having both a host featureset and
a host policy in the same context.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
tools/libs/guest/xg_cpuid_x86.c | 27 -
Rename xc_cpuid_xend_policy to xc_cpu_policy_apply_cpuid and make it
public. Modify the function internally to use the new xc_cpu_policy_*
set of functions. Also don't apply the passed policy to a domain
directly, and instead modify the provided xc_cpu_policy_t. The caller
will be responsible of ap
Currently libxl_cpuid_policy_list is an opaque type to the users of
libxl, and internally it's an array of xc_xend_cpuid objects.
Change the type to instead be a structure that contains one array for
CPUID policies, in preparation for it also holding another array for
MSR policies.
Signed-off-by:
On 16/06/2023 1:12 pm, Jan Beulich wrote:
> On 15.06.2023 20:17, Andrew Cooper wrote:
>> On 15/06/2023 1:13 pm, Jan Beulich wrote:
>>> On 15.06.2023 12:41, Andrew Cooper wrote:
On 15/06/2023 9:30 am, Jan Beulich wrote:
> On 14.06.2023 20:12, Andrew Cooper wrote:
>> On 13/06/2023 10:59
Move the CPUID value parsers out of libxl_cpuid_parse_config() into a
newly created cpuid_add() local helper. This is in preparation for
also adding MSR feature parsing support.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
tools/libs/light/libxl_cpuid.c | 120 +
Add a new array field to libxl_cpuid_policy in order to store the MSR
policies.
Note that libxl_cpuid_policy_list_{copy,length,parse_json,gen_json}
are not adjusted to deal with the new MSR array now part of
libxl_cpuid_policy_list.
Adding the MSR data in the libxl_cpuid_policy_list type is done
Like it's done with CPUID, introduce support for passing MSR values to
xc_cpuid_apply_policy(). The chosen format for expressing MSR policy
data matches the current one used for CPUID. Note that existing
callers of xc_cpuid_apply_policy() can pass NULL as the value for the
newly introduced 'msr'
Introduce support for handling MSR features in
libxl_cpuid_parse_config(). The MSR policies are added to the
libxl_cpuid_policy like the CPUID one, which gets passed to
xc_cpuid_apply_policy().
This allows existing users of libxl to provide MSR related features as
key=value pairs to libxl_cpuid_p
The current implementation in libxl_cpuid_parse_config() requires
keeping a list of cpuid feature bits that should be mostly in sync
with the contents of cpufeatureset.h.
Avoid such duplication by using the automatically generated list of
cpuid features in INIT_FEATURE_NAMES in order to map featur
On Thu, Jun 15, 2023 at 04:56:22PM +0200, Jan Beulich wrote:
> For an approach like that used in "x86: detect PIT aliasing on ports
> other than 0x4[0-3]" [1] to work, channel 2 may not (appear to) continue
> counting when "gate" is low. Record the time when "gate" goes low, and
> adjust pit_get_{c
On Fri, Jun 16, 2023 at 12:52 PM Jan Beulich wrote:
> On 16.06.2023 13:47, Olaf Hering wrote:
> > Wed, 31 May 2023 11:05:52 +0200 Jan Beulich :
> >
> >> As said before, num_online_cpus() will under-report for the purpose
> >> here, as CPUs may have been brought offline, and may be brought online
On Wed, Jun 14, 2023 at 03:57:11PM -0400, Jason Andryuk wrote:
> Hi, Roger,
>
> On Mon, Nov 21, 2022 at 10:04 AM Roger Pau Monné wrote:
> >
> > On Mon, Nov 21, 2022 at 03:10:36PM +0100, Jan Beulich wrote:
> > > On 21.11.2022 11:21, Roger Pau Monne wrote:
> > > > --- a/drivers/acpi/processor_pdc.c
On 16/06/23 12:03, Jan Beulich wrote:
On 16.06.2023 09:45, Roberto Bagnara wrote:
On 16/06/23 08:53, Jan Beulich wrote:
On 16.06.2023 01:26, Stefano Stabellini wrote:
+ * - Unspecified escape sequence is encountered in a character constant or a
string literal token
+ - X86_64
+ - \\
On 13/06/2023 3:49 pm, Shawn Anastasio wrote:
> Add a container for cross-compiling xen for ppc64le.
>
> Signed-off-by: Shawn Anastasio
Acked-by: Andrew Cooper
I've built and deployed this container properly, replacing the prototype
from earlier.
Fri, 16 Jun 2023 15:22:24 +0100 George Dunlap :
> I agree; the clear implication is that with smt=0, you might have
> num_online_cpus() return 4, but cpuids that look like {1, 3, 5, 7}; so you
> need the trace buffer array to be of size 8.
I see. Apparently some remapping is required to map a cpu
On 16/06/23 01:26, Stefano Stabellini wrote:
On Thu, 15 Jun 2023, Roberto Bagnara wrote:
This document specifies the C language dialect used by Xen and
the assumptions Xen makes on the translation toolchain.
Signed-off-by: Roberto Bagnara
Thanks Roberto for the amazing work of research and a
On 16/06/2023 4:37 pm, Olaf Hering wrote:
> Fri, 16 Jun 2023 15:22:24 +0100 George Dunlap :
>
>> I agree; the clear implication is that with smt=0, you might have
>> num_online_cpus() return 4, but cpuids that look like {1, 3, 5, 7}; so you
>> need the trace buffer array to be of size 8.
> I see. A
On Tue, Jun 13, 2023 at 10:32:26AM +, Volodymyr Babchuk wrote:
> From: Oleksandr Andrushchenko
>
> Introduce a per-domain read/write lock to check whether vpci is present,
> so we are sure there are no accesses to the contents of the vpci struct
> if not. This lock can be used (and in a few c
On Thu Jun 15, 2023 at 1:47 AM CDT, Jan Beulich wrote:
> On 14.06.2023 18:36, Shawn Anastasio wrote:
> > On Wed Jun 14, 2023 at 10:51 AM CDT, Jan Beulich wrote:
> >> On 13.06.2023 16:50, Shawn Anastasio wrote:
> >>> +DECL_SECTION(.bss) { /* BSS */
> >>> +__bss_start
flight 181466 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181466/
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
Add build jobs to cross-compile Xen for ppc64le.
Signed-off-by: Shawn Anastasio
---
automation/gitlab-ci/build.yaml | 60 +
1 file changed, 60 insertions(+)
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index 420ffa5acb..bd8c7332d
Hello all,
This patch series adds support for building a minimal image
for Power ISA 2.07B+ (POWER8+) systems. In addition to a patch adding
support to the build system and a simple infinite loop at the
entrypoint, patches to add ppc64le support to the CI as well as a
MAINTAINERS update are includ
Add the build system changes required to build for ppc64le (POWER8+).
As of now the resulting image simply boots to an infinite loop.
$ make XEN_TARGET_ARCH=ppc64 -C xen openpower_defconfig
$ make XEN_TARGET_ARCH=ppc64 SUBSYSTEMS=xen -C xen build
This port targets POWER8+ CPUs running in Little E
Add a container for cross-compiling xen for ppc64le.
Signed-off-by: Shawn Anastasio
Acked-by: Andrew Cooper
---
.../build/debian/bullseye-ppc64le.dockerfile | 28 +++
automation/scripts/containerize | 1 +
2 files changed, 29 insertions(+)
create mode 100644 aut
Signed-off-by: Shawn Anastasio
---
MAINTAINERS | 4
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1bb7a6a839..25139fe4a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -460,6 +460,10 @@ X: xen/arch/x86/acpi/lib.c
F: xen/drivers/cpufreq/
F: xen/include
The asm forming early error handling is a mix of local and non-local symbols,
and has some pointless comments. Drop the "# Error message" comments,
tweaking the style on modified lines, and make the symbols local.
However, leave behind one real symbol so this logic disassembles nicely
without mer
On Fri, 16 Jun 2023, Shawn Anastasio wrote:
> Add a container for cross-compiling xen for ppc64le.
>
> Signed-off-by: Shawn Anastasio
> Acked-by: Andrew Cooper
Acked-by: Stefano Stabellini
> ---
> .../build/debian/bullseye-ppc64le.dockerfile | 28 +++
> automation/scripts/co
On Fri, 16 Jun 2023, Shawn Anastasio wrote:
> Add build jobs to cross-compile Xen for ppc64le.
>
> Signed-off-by: Shawn Anastasio
Acked-by: Stefano Stabellini
> ---
> automation/gitlab-ci/build.yaml | 60 +
> 1 file changed, 60 insertions(+)
>
> diff --git a/
On 15/06/2023 4:31 pm, Alejandro Vallejo wrote:
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 09bebf8635..ce62eae6f3 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -142,8 +142,8 @@ efi_platform:
>
> .section .init.text, "ax", @p
On 15/06/2023 4:31 pm, Alejandro Vallejo wrote:
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 406445a358..fa97d4 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -307,6 +307,22 @@ config MEM_SHARING
> bool "Xen memory sharing support (UNSUPPORTED)
On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
> Add a container for cross-compiling xen for ppc64le.
>
> Signed-off-by: Shawn Anastasio
> Acked-by: Andrew Cooper
Just to say that I already committed this patch, when rebuilding the
container. We likely raced given the time you posted the series,
On 6/16/23 2:49 PM, Andrew Cooper wrote:
> On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
>> Add a container for cross-compiling xen for ppc64le.
>>
>> Signed-off-by: Shawn Anastasio
>> Acked-by: Andrew Cooper
> Just to say that I already committed this patch, when rebuilding the
> container. We
On Fri, 16 Jun 2023, Luca Fancellu wrote:
> > On 15 Jun 2023, at 22:27, Stefano Stabellini wrote:
> >
> > From: Stefano Stabellini
> >
> > Also add a comment at the top of the file to say rules.rst could be
> > changed.
> >
> > Signed-off-by: Stefano Stabellini
>
> Hi Stefano,
>
> Reviewed-
On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
> Add the build system changes required to build for ppc64le (POWER8+).
> As of now the resulting image simply boots to an infinite loop.
>
> $ make XEN_TARGET_ARCH=ppc64 -C xen openpower_defconfig
> $ make XEN_TARGET_ARCH=ppc64 SUBSYSTEMS=xen -C xen bu
On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
> Add build jobs to cross-compile Xen for ppc64le.
>
> Signed-off-by: Shawn Anastasio
Acked-by: Andrew Cooper
On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
> diff --git a/xen/arch/ppc/ppc64/head.S b/xen/arch/ppc/ppc64/head.S
> new file mode 100644
> index 00..0b289c713a
> --- /dev/null
> +++ b/xen/arch/ppc/ppc64/head.S
> @@ -0,0 +1,27 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +.se
Hi,
On 15/06/2023 09:05, Michal Orzel wrote:
/*
* Restrict "p2m_ipa_bits" if needed. As P2M table is always configured
* with IPA bits == PA bits, compare against "pabits".
@@ -2291,6 +2299,7 @@ void __init setup_virt_paging(void)
*/
if ( system_cpuinfo.mm64.vmid
On 16/06/2023 08:59, Michal Orzel wrote:
Hi Julien,
On 15/06/2023 22:32, Julien Grall wrote:
Hi Michal,
I notice you posted some comments but didn't add a Acked-by/Reviewed-by.
Can you indicate if you are happy with the patch so long your comments
are addressed?
If so, are you OK if I de
On Thu, Jun 15, 2023 at 12:57:19AM -0700, Hugh Dickins wrote:
> Probably just trivial collisions in most architectures, which either
> of us can easily adjust to the other; powerpc likely to be more awkward,
> but fairly easily resolved; s390 quite a problem.
>
> I've so far been unable to post a
Hi,
On 16/06/2023 21:24, Andrew Cooper wrote:
--- /dev/null
+++ b/xen/arch/ppc/ppc64/head.S
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+.section .text.header, "ax", %progbits
+
+ENTRY(start)
+/*
+ * Depending on how we were booted, the CPU could be running in eit
flight 181467 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181467/
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, 16 Jun 2023, Roberto Bagnara wrote:
> > > + * - Implicit conversion from a pointer to an incompatible pointer
> > > + - ARM64, X86_64
> > > + - Non-documented GCC extension.
> >
> > Is this related to -Wincompatible-pointer-types?
>
> In my opinion, this does not specify what th
Hi Jan,
Sorry for the late reply.
On 26/04/2022 11:27, Jan Beulich wrote:
Let's try to avoid giving the impression that 32-bit tool stacks are as
capable as 64-bit ones.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--
Julien Grall
Hi,
On 15/06/2023 22:52, Jiatong Shen wrote:
Thank you for your answer! Adding console=hvc0 indeed provides kernel
output serial console. Looking at the log message,
I found dom0 kernel failed to initialize a lot of device drivers (network
cards, raid cards, etc).
Is it related to iomm
On Fri, 16 Jun 2023, Nicola Vetrini wrote:
> On 16/06/23 09:19, Jan Beulich wrote:
> > On 15.06.2023 18:39, nicola wrote:
> > > while investigating possible patches regarding Mandatory Rule 9.1, I
> > > found the following pattern, that is likely to results in a lot possible
> > > positives from ma
On 6/16/23 3:27 PM, Andrew Cooper wrote:
> Sorry, I also meant to ask. How prevalent is Big Endian in practice in
> the Power world?
Modern systems support operating in either endianness, but historically
most operating systems targeted Big Endian-only, and some older systems
didn't support Littl
flight 181460 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181460/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd broken
Tests which did not
flight 181463 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181463/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 180691
build-arm64
On Thu, Jun 15, 2023 at 12:57 AM Hugh Dickins wrote:
>
> On Mon, 12 Jun 2023, Vishal Moola (Oracle) wrote:
>
> > Currently, page table information is stored within struct page. As part
> > of simplifying struct page, create struct ptdesc for page table
> > information.
> >
> > Signed-off-by: Visha
flight 181470 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181470/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 5 hos
flight 181462 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181462/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds broken
test-armhf-armhf-xl
flight 181473 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181473/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
test-armhf-arm
flight 181472 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181472/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 180691
build-arm64
flight 181464 linux-linus real [real]
flight 181475 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181464/
http://logs.test-lab.xenproject.org/osstest/logs/181475/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
80 matches
Mail list logo
