On 28.08.2023 19:56, Stewart Hildebrand wrote:
> These were left over after a previous pci_sbdf_t conversion.
>
> Fixes: 0c38c61aad21 ("pci: switch pci_conf_write32 to use pci_sbdf_t")
> Signed-off-by: Stewart Hildebrand
Reviewed-by: Jan Beulich
On 28.08.2023 15:20, Simone Ballarin wrote:
> --- a/xen/include/xen/unaligned.h
> +++ b/xen/include/xen/unaligned.h
> @@ -3,13 +3,14 @@
> * without faulting, and at least reasonably efficiently. Other
> architectures
> * will need to have a custom asm/unaligned.h.
> */
> -#ifndef __ASM_UNAL
On 28.08.2023 15:20, Simone Ballarin wrote:
> Add inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Also C files, if included somewhere, need to comply with
On 29.08.2023 00:42, Stefano Stabellini wrote:
> On Mon, 28 Aug 2023, Simone Ballarin wrote:
>> --- a/xen/common/efi/runtime.c
>> +++ b/xen/common/efi/runtime.c
>> @@ -6,6 +6,10 @@
>> #include
>> #include
>>
>> +#ifndef __COMMON_EFI_RUNTIME_C__
>> +#define __COMMON_EFI_RUNTIME_C__
>
> Should
On 28.08.2023 15:20, Simone Ballarin wrote:
> --- a/xen/arch/x86/include/asm/hypercall.h
> +++ b/xen/arch/x86/include/asm/hypercall.h
> @@ -2,13 +2,13 @@
> * asm-x86/hypercall.h
> */
>
> +#ifndef __ASM_X86_HYPERCALL_H__
> +#define __ASM_X86_HYPERCALL_H__
> +
> #ifndef __XEN_HYPERCALL_H__
>
On 29.08.2023 00:27, Stefano Stabellini wrote:
> On Mon, 28 Aug 2023, Simone Ballarin wrote:
>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -96,6 +96,10 @@ conform to the directive."
>> -config=MC3R1.D4.10,reports+={safe, "
On 28.08.2023 15:19, Simone Ballarin wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -80,6 +80,7 @@ inline functions."
>
> -doc_begin="This header file is autogenerated or empty, therefore it poses no
> risk if includ
On 28.08.2023 15:19, Simone Ballarin wrote:
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -60,7 +60,8 @@ maintainers if you want to suggest a change.
> - Precautions shall be taken in order to prevent the contents of a
> header file being included more than once
>
On 28.08.2023 23:52, Stefano Stabellini wrote:
> On Mon, 28 Aug 2023, Jan Beulich wrote:
>> On 26.08.2023 00:21, Stefano Stabellini wrote:
>>> Coming to unsigned int, it should be 32-bit on all supported arches,
>>
>> But this isn't a requirement, even if we're using "unsigned int" in the
>> C decl
flight 182549 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182549/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a107fcb618934ae18f29660ecf066f3c49dd875f
baseline version:
ovmf b1e558f6369fc85ae053e
flight 182543 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182543/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 182520
test-armhf-armhf-libvirt-qcow2 15 s
flight 182547 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182547/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b1e558f6369fc85ae053e0c16ffcd600880fe78d
baseline version:
ovmf 2c7fd32676272e22ed44f
flight 182542 xen-unstable real [real]
flight 182546 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/182542/
http://logs.test-lab.xenproject.org/osstest/logs/182546/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
On 8/28/23 13:56, Stewart Hildebrand wrote:
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index 4a4dbb69ab1c..919addbfa630 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -561,6 +573,71 @@ static int cf_check init_bars(struct pci_dev *pdev)
>
flight 182545 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182545/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2c7fd32676272e22ed44fdfc8fa7e47f5c7a93b8
baseline version:
ovmf 92006e5804a4adff05556
The pull request you sent on Thu, 24 Aug 2023 16:36:26 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-6.6-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6383cb42ac01e6fb9ef6a035a2288786e61bdddf
Thank you!
--
Deet-doot-dot, I
On Mon, 28 Aug 2023, Simone Ballarin wrote:
> Move or amended inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Inclusion guards must appear at the beginnin
On Mon, 28 Aug 2023, Simone Ballarin wrote:
> Amend generation script to address a violation of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> This patch adds a special comment to the beginning o
On Mon, 28 Aug 2023, Simone Ballarin wrote:
> Add inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Mechanical change.
>
> Signed-off-by: Simone Ballarin
On Mon, 28 Aug 2023, Simone Ballarin wrote:
> Add inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Also C files, if included somewhere, need to comply with
On Mon, 28 Aug 2023, Simone Ballarin wrote:
> Add inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Also C files, if included somewhere, need to comply with
On Mon, 28 Aug 2023, Simone Ballarin wrote:
> Add inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> C files, if included somewhere, need to comply with the
On Mon, 28 Aug 2023, Stefano Stabellini wrote:
> On Mon, 28 Aug 2023, Simone Ballarin wrote:
> > Some headers, under specific circumstances (documented in a comment at
> > the beginning of the file), explicitly avoid inclusion guards: the caller
> > is responsible for including them correctly.
> >
On Mon, 28 Aug 2023, Simone Ballarin wrote:
> Add or move inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Inclusion guards must appear at the beginning of
On Mon, 28 Aug 2023, Simone Ballarin wrote:
> Add inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Mechanical change.
>
> Signed-off-by: Simone Ballarin
+Nicola, Luca
On Mon, 28 Aug 2023, Simone Ballarin wrote:
> xen/arch/x86/usercopy.c includes itself, so it is not supposed to
> comply with Directive 4.10:
> "Precautions shall be taken in order to prevent the contents of a
> header file being included more than once"
>
> This patch adds a deviat
On Mon, 28 Aug 2023, Simone Ballarin wrote:
> Add or move inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Inclusion guards must appear at the beginning of
Hi,
On Mon, 28 Aug 2023 at 09:20, Simone Ballarin
wrote:
> Add or move inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Inclusion guards must appear at t
On Mon, 28 Aug 2023, Simone Ballarin wrote:
> Add or move inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Inclusion guards must appear at the beginning of
On Mon, 28 Aug 2023, Simone Ballarin wrote:
> This patch adds a text-based deviation for Directive 4.10:
> "Precautions shall be taken in order to prevent the contents of
> a header file being included more than once"
>
> Headers starting with the following comment are not supposed to
> comply wit
On Mon, 28 Aug 2023, Simone Ballarin wrote:
> Some headers, under specific circumstances (documented in a comment at
> the beginning of the file), explicitly avoid inclusion guards: the caller
> is responsible for including them correctly.
>
> These files are not supposed to comply with Directive
On Mon, 28 Aug 2023, Jan Beulich wrote:
> On 26.08.2023 00:21, Stefano Stabellini wrote:
> > Coming to unsigned int, it should be 32-bit on all supported arches,
>
> But this isn't a requirement, even if we're using "unsigned int" in the
> C declarations / definitions: If "unsigned int" was wider,
Hi,
I've noticed in Qubes's CI failure like this:
[ 871.271292] BUG: kernel NULL pointer dereference, address:
[ 871.275290] #PF: supervisor read access in kernel mode
[ 871.277282] #PF: error_code(0x) - not-present page
[ 871.279182] PGD 106fdb067 P4D 106fdb067 PUD 106fd
Currently, Xen vPCI only supports virtualizing the MSI and MSI-X capabilities.
Hide all other PCI capabilities (including extended capabilities) from domUs for
now, even though there may be certain devices/drivers that depend on being able
to discover certain capabilities.
We parse the physical PC
Add support for a read-only bit mask for vPCI register handlers.
Signed-off-by: Stewart Hildebrand
---
v3->v4:
* new patch
RFC: It seemed like a low-hanging fruit to add support for ro mask. Let me know
what you think, and I could squash it into the status handler patch for the
next ve
Introduce a handler for the PCI status register, with ability to mask the
capabilities bit. The status register is write-1-to-clear, so introduce handling
for this type of register in vPCI.
The mask_cap_list flag will be set in a follow-on patch.
Signed-off-by: Stewart Hildebrand
---
v3->v4:
* m
Use pdev->sbdf instead of the PCI_SBDF macro in calls to pci_* functions
where appropriate. Move NULL check earlier.
Suggested-by: Jan Beulich
Signed-off-by: Stewart Hildebrand
---
v3->v4:
* new patch
Suggested-by tag added based on conversation at [1]
[1] https://lists.xenproject.org/archives
Convert pci_find_*cap* functions and call sites to pci_sbdf_t, and remove some
now unused local variables. Also change to more appropriate types on lines that
are already being modified as a result of the pci_sbdf_t conversion.
Signed-off-by: Stewart Hildebrand
---
I built with EXTRA_CFLAGS_XEN_C
These were left over after a previous pci_sbdf_t conversion.
Fixes: 0c38c61aad21 ("pci: switch pci_conf_write32 to use pci_sbdf_t")
Signed-off-by: Stewart Hildebrand
---
v3->v4:
* new patch: this change was split from
("xen/pci: convert pci_find_*cap* to pci_sbdf_t")
Found by building with EXT
This small series enables vPCI to filter which PCI capabilities we expose to a
domU. This series adds vPCI register handlers within
xen/drivers/vpci/header.c:init_bars(), along with some supporting functions.
Note there are minor rebase conflicts with the in-progress vPCI series [1].
These conflic
On Fri 25-08-23 15:32:47, Christian Brauner wrote:
> On Wed, Aug 23, 2023 at 12:48:11PM +0200, Jan Kara wrote:
> > Hello,
> >
> > this is a v3 of the patch series which implements the idea of
> > blkdev_get_by_*()
> > calls returning bdev_handle which is then passed to blkdev_put() [1]. This
> >
On Fri, Aug 25, 2023 at 01:02:12AM -0700, Vikram Garhwal wrote:
> Protect iommu_add_dt_device() with dtdevs_lock to prevent concurrent access
> to add/remove/assign/deassign.
> With addition of dynamic programming feature(follow-up patches in this
> series),
> this function can be concurrently acc
flight 182541 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182541/
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, Aug 25, 2023 at 01:02:16AM -0700, Vikram Garhwal wrote:
> Dynamic programming ops will modify the dt_host and there might be other
> functions which are browsing the dt_host at the same time. To avoid the race
> conditions, adding rwlock for browsing the dt_host during runtime. dt_host
> wr
Hi Henry,
On Mon, Aug 28, 2023 at 01:53:15AM +, Henry Wang wrote:
> Hi Vikram,
>
> > On Aug 25, 2023, at 16:02, Vikram Garhwal wrote:
> >
> > +
> > +/*
> > + * handle_device_interrupts retrieves the interrupts configuration from
> > + * a device tree node and maps those interrupts to the tar
On 28.08.2023 12:14, Roger Pau Monne wrote:
> The return value of bogus_8259A_irq() is wrong: the function will
> return `true` when the IRQ is real and `false` when it's a spurious
> IRQ. This causes the "No irq handler for vector ..." message in
> do_IRQ() to be printed for spurious i8259 interr
On 28.08.2023 17:57, Oleksii Kurochko wrote:
> asm/vm_event.h is common for ARM and RISC-V so it will be moved to
> stubs dir.
>
> Original asm/vm_event.h from ARM was updated:
> * use SPDX-License-Identifier.
> * update comment messages of stubs.
> * update #ifdef
When generalizing such a hea
asm/vm_event.h is common for ARM and RISC-V so it will be moved to
stubs dir.
Original asm/vm_event.h from ARM was updated:
* use SPDX-License-Identifier.
* update comment messages of stubs.
* update #ifdef
Signed-off-by: Oleksii Kurochko
---
xen/arch/arm/include/asm/vm_event.h | 66
A lot of empty/stub headers should be introduced during the early steps of
adding
support of new architecture.
An example can be found here:
1.
https://lore.kernel.org/xen-devel/cover.1692181079.git.oleksii.kuroc...@gmail.com/
2.
https://lore.kernel.org/xen-devel/a92f99e8f697da99d77bfde562a549d
stubs dir will contain empty/stubs generic for all architectures
headers.
Signed-off-by: Oleksii Kurochko
---
xen/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/Makefile b/xen/Makefile
index f57e5a596c..64c3542c84 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -438,6 +438,7 @@
This patch adds a text-based deviation for Directive 4.10:
"Precautions shall be taken in order to prevent the contents of
a header file being included more than once"
Headers starting with the following comment are not supposed to
comply with the directive:
"/* empty */"
These headers should be
Move or amended inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Inclusion guards must appear at the beginning of the headers
(comments are permitted anywhere) and t
Some headers, under specific circumstances (documented in a comment at
the beginning of the file), explicitly avoid inclusion guards: the caller
is responsible for including them correctly.
These files are not supposed to comply with Directive 4.10:
"Precautions shall be taken in order to prevent
Add or move inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Inclusion guards must appear at the beginning of the headers
(comments are permitted anywhere).
Also C
Add or move inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Inclusion guards must appear at the beginning of the headers
(comments are permitted anywhere).
Mechani
xen/arch/x86/usercopy.c includes itself, so it is not supposed to
comply with Directive 4.10:
"Precautions shall be taken in order to prevent the contents of a
header file being included more than once"
This patch adds a deviation for the file.
Signed-off-by: Simone Ballarin
---
automation/ecla
Add inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
C files, if included somewhere, need to comply with the guideline.
Mechanical change.
Signed-off-by: Simone Ba
Amend generation script to address a violation of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
This patch adds a special comment to the beginning of the header
to make it explicit that the file is genera
Add inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Also C files, if included somewhere, need to comply with the guideline.
Mechanical change.
Signed-off-by: Simo
Add or move inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Inclusion guards must appear at the beginning of the headers
(comments are permitted anywhere).
The tex
Add or move inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Inclusion guards must appear at the beginning of the headers
(comments are permitted anywhere) and the #
Add inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Mechanical change.
Signed-off-by: Simone Ballarin
---
xen/common/sched/compat.c | 6 ++
1 file changed, 6
> So besides my last fput() worry about I think this could work and would be
> probably a bit nicer than what I have. But before going and redoing the whole
> series let me gather some more feedback so that we don't go back and forth.
> Christoph, Christian, Jens, any opinion?
I'll be a bit under
Add inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Mechanical change.
Signed-off-by: Simone Ballarin
---
xen/arch/x86/efi/efi-boot.h | 6 ++
xen/arch/x86/ef
Add inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Also C files, if included somewhere, need to comply with the guideline.
Mechanical change.
Signed-off-by: Simo
On Sat, Aug 26, 2023 at 03:28:52AM +0100, Al Viro wrote:
> I mean, look at claim_swapfile() for example:
> p->bdev = blkdev_get_by_dev(inode->i_rdev,
>FMODE_READ | FMODE_WRITE | FMODE_EXCL, p);
> if (IS_ERR(p->bdev)) {
>
On Fri, Aug 25, 2023 at 03:47:56PM +0200, Jan Kara wrote:
> I can see the appeal of not having to introduce the new bdev_handle type
> and just using struct file which unifies in-kernel and userspace block
> device opens. But I can see downsides too - the last fput() happening from
> task work make
(reducing Cc list)
On 28.08.2023 14:41, Simone Ballarin wrote:
> On 23/08/23 10:15, Jan Beulich wrote:
>> On 03.08.2023 12:22, Simone Ballarin wrote:
>>> This series aims to address some violations ofMISRA C:2012 Rule 7.3:
>>> "The lowercase character 'l' shall not be used in a literal suffix".
>>
On 23/08/23 10:15, Jan Beulich wrote:
On 03.08.2023 12:22, Simone Ballarin wrote:
This series aims to address some violations ofMISRA C:2012 Rule 7.3:
"The lowercase character 'l' shall not be used in a literal suffix".
This patch replaces "l" suffixes with "L", to comply with the rule.
If the
flight 182538 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182538/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 92006e5804a4adff05556a97a951fd7766a1d79f
baseline version:
ovmf 819cfc6b42a68790a2350
From: Gianluca Luparini
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type.
Use _AC() for macro co
From: Gianluca Luparini
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type and also to other
liter
From: Gianluca Luparini
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type and also to other
liter
From: Gianluca Luparini
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type.
For the sake of unifo
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose headline
states:
"A 'u' or 'U' suffix shall be applied to all integer constants that are
represented in an unsigned type".
These violations are caused by the missing "u" or "U" suffix in unsigned
integer constants, such as:
xen/ar
flight 182532 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182532/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-qcow2 13 guest-startfail in 182527 pass in 182532
test-amd64-i386-qemut-rhel6hvm-a
The return value of bogus_8259A_irq() is wrong: the function will
return `true` when the IRQ is real and `false` when it's a spurious
IRQ. This causes the "No irq handler for vector ..." message in
do_IRQ() to be printed for spurious i8259 interrupts which is not
intended (and not helpful).
Fix b
On 27 Jul 2023, Jan Beulich wrote:
On 26.07.2023 13:03, Simone Ballarin wrote:
> >* @@ -70,15 +70,15 @@ static const uint8_t sr_mask[8] = {*
> >* };*
> >
> >* static const uint8_t gr_mask[9] = {*
> >* -(uint8_t)~0xf0, /* 0x00 */*
> >* -(uint8_t)~0xf0, /* 0x01 */*
> >* -(uint8_t)~0xf0
flight 182536 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182536/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 182513
build-i386
On 25.08.2023 17:02, Nicola Vetrini wrote:
> The common header file for ioreq should include the arch-specific one.
To be honest I'm not convinced of "should" here. There are two aspects
to consider: On one hand it is good practice to do what you say. Otoh it
introduces a needless dependency, and
flight 182531 linux-linus real [real]
flight 182533 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/182531/
http://logs.test-lab.xenproject.org/osstest/logs/182533/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-
flight 182534 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182534/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 182513
Tests which did not succee
82 matches
Mail list logo
