flight 187117 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187117/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 87d3a6272ca8637787813256c1a2435e89e326e2
baseline version:
ovmf bbee1cc852fa8676ed0b5
Done.
On 8/2/24 09:06, Baoquan He wrote:
On 07/31/24 at 06:34pm, A Kundu wrote:
I am experiencing issues using kexec to load Xen 4.17(debian's apt version),
Xen 4.19-rc4 (compiled from source) and 4.20-dev (compiled from source) on a
debian host.
You should CC this to XEN dev list so that XEN
On 2024/8/2 14:25, Jan Beulich wrote:
> On 02.08.2024 04:55, Chen, Jiqian wrote:
>> On 2024/7/31 23:55, Roger Pau Monné wrote:
>>> On Mon, Jul 08, 2024 at 07:41:18PM +0800, Jiqian Chen wrote:
When a device has been reset on dom0 side, the Xen hypervisor
doesn't get notification, so the ca
On 02.08.2024 09:41, Chen, Jiqian wrote:
> On 2024/8/2 14:25, Jan Beulich wrote:
>> On 02.08.2024 04:55, Chen, Jiqian wrote:
>>> On 2024/7/31 23:55, Roger Pau Monné wrote:
On Mon, Jul 08, 2024 at 07:41:18PM +0800, Jiqian Chen wrote:
> @@ -305,6 +312,15 @@ struct physdev_pci_device {
>
On 2024/8/2 14:27, Jan Beulich wrote:
> On 02.08.2024 05:10, Chen, Jiqian wrote:
>> On 2024/8/1 19:06, Roger Pau Monné wrote:
>>> On Mon, Jul 08, 2024 at 07:41:21PM +0800, Jiqian Chen wrote:
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -464,6 +464,13 @@ stru
On Fri, Aug 02, 2024 at 08:25:58AM +0200, Jan Beulich wrote:
> On 02.08.2024 04:55, Chen, Jiqian wrote:
> > On 2024/7/31 23:55, Roger Pau Monné wrote:
> >> On Mon, Jul 08, 2024 at 07:41:18PM +0800, Jiqian Chen wrote:
> >>> When a device has been reset on dom0 side, the Xen hypervisor
> >>> doesn't
On 02.08.2024 09:28, A Kundu wrote:
> On 8/2/24 09:06, Baoquan He wrote:
>> On 07/31/24 at 06:34pm, A Kundu wrote:
>>> I am experiencing issues using kexec to load Xen 4.17(debian's apt version),
>>> Xen 4.19-rc4 (compiled from source) and 4.20-dev (compiled from source) on a
>>> debian host.
>> Yo
On Fri, Aug 02, 2024 at 08:33:09AM +0200, Jan Beulich wrote:
> On 01.08.2024 23:38, osstest service owner wrote:
> > flight 187097 xen-4.19-testing real [real]
> > flight 187112 xen-4.19-testing real-retest [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/187097/
> > http://logs.test-lab
Currently, writing at cpu//availability in xenstore fails for a
couple of reasons: a trailing slash in the path and the fact that
cpupool isn't a bitmap but the cpupool id. This patch fixes this by
just getting libxl_vcpuinfo for each dom0less domain.
Signed-off-by: Amneesh Singh
---
tools/helpe
On Fri, Aug 02, 2024 at 03:10:27AM +, Chen, Jiqian wrote:
> On 2024/8/1 19:06, Roger Pau Monné wrote:
> > We might as well declare the flags field as uint32_t and avoid the
> > padding field.
> So, should this struct be like below? Then I just need to check whether
> everything except the lowe
On Mon, Jul 08, 2024 at 07:41:21PM +0800, Jiqian Chen wrote:
> Some type of domains don't have PIRQs, like PVH, it doesn't do
> PHYSDEVOP_map_pirq for each gsi. When passthrough a device
> to guest base on PVH dom0, callstack
> pci_add_dm_done->XEN_DOMCTL_irq_permission will fail at function
> doma
On Fri, Aug 02, 2024 at 02:37:24AM +, Chen, Jiqian wrote:
> On 2024/7/31 21:03, Roger Pau Monné wrote:
> > On Wed, Jul 31, 2024 at 01:39:40PM +0200, Jan Beulich wrote:
> >> On 31.07.2024 13:29, Roger Pau Monné wrote:
> >>> On Wed, Jul 31, 2024 at 11:55:35AM +0200, Jan Beulich wrote:
> On 3
On 2024/8/2 16:08, Roger Pau Monné wrote:
> On Mon, Jul 08, 2024 at 07:41:21PM +0800, Jiqian Chen wrote:
>> Some type of domains don't have PIRQs, like PVH, it doesn't do
>> PHYSDEVOP_map_pirq for each gsi. When passthrough a device
>> to guest base on PVH dom0, callstack
>> pci_add_dm_done->XEN_DO
On 2024/8/2 16:11, Roger Pau Monné wrote:
> On Fri, Aug 02, 2024 at 02:37:24AM +, Chen, Jiqian wrote:
>> On 2024/7/31 21:03, Roger Pau Monné wrote:
>>> On Wed, Jul 31, 2024 at 01:39:40PM +0200, Jan Beulich wrote:
On 31.07.2024 13:29, Roger Pau Monné wrote:
> On Wed, Jul 31, 2024 at 11:
On Fri, Aug 02, 2024 at 08:17:15AM +, Chen, Jiqian wrote:
> On 2024/8/2 16:11, Roger Pau Monné wrote:
> > On Fri, Aug 02, 2024 at 02:37:24AM +, Chen, Jiqian wrote:
> >> On 2024/7/31 21:03, Roger Pau Monné wrote:
> >>> On Wed, Jul 31, 2024 at 01:39:40PM +0200, Jan Beulich wrote:
> On 31
Hi Jan,
On 2024/8/2 16:35, Roger Pau Monné wrote:
> On Fri, Aug 02, 2024 at 08:17:15AM +, Chen, Jiqian wrote:
>> On 2024/8/2 16:11, Roger Pau Monné wrote:
>>> I think this patch needs to be adjusted to drop the change to
>>> xen/arch/x86/physdev.c, as just allowing PHYSDEVOP_{,un}map_pirq
>>>
flight 187113 xen-4.19-testing real [real]
flight 187119 xen-4.19-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187113/
http://logs.test-lab.xenproject.org/osstest/logs/187119/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
If this memcmp() is not inlined then PVH early boot code can call
into KASAN-instrumented memcmp() which results in unbootable VMs:
pvh_start_xen
xen_prepare_pvh
xen_cpuid_base
hypervisor_cpuid_base
memcmp
Ubuntu's gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1
If this memset() is not inlined than PVH early boot code can call
into KASAN-instrumented memset() which results in unbootable VMs.
Ubuntu's 22.04.4 LTS gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
doesn't inline this memset but inlines __builtin_memset.
Signed-off-by: Alexey Dobriyan
---
On Mon, 2024-07-29 at 15:00 +0200, Jan Beulich wrote:
> > To have working BUG(), WARN(), ASSERT, run_in_exception_handler()
> > it is needed to enable GENERIC_BUG_FRAME.
> >
> > ebreak is used as BUG_insn so when macros from are
> > used, an exception with BREAKPOINT cause will be generated.
> >
On 02.08.2024 09:55, Anthony PERARD wrote:
> On Fri, Aug 02, 2024 at 08:33:09AM +0200, Jan Beulich wrote:
>> On 01.08.2024 23:38, osstest service owner wrote:
>>> flight 187097 xen-4.19-testing real [real]
>>> flight 187112 xen-4.19-testing real-retest [real]
>>> http://logs.test-lab.xenproject.org
On 02.08.2024 10:40, Chen, Jiqian wrote:
> On 2024/8/2 16:35, Roger Pau Monné wrote:
>> On Fri, Aug 02, 2024 at 08:17:15AM +, Chen, Jiqian wrote:
>>> On 2024/8/2 16:11, Roger Pau Monné wrote:
I think this patch needs to be adjusted to drop the change to
xen/arch/x86/physdev.c, as just
On 02.08.2024 11:14, oleksii.kuroc...@gmail.com wrote:
> On Mon, 2024-07-29 at 15:00 +0200, Jan Beulich wrote:
>>> To have working BUG(), WARN(), ASSERT, run_in_exception_handler()
>>> it is needed to enable GENERIC_BUG_FRAME.
>>>
>>> ebreak is used as BUG_insn so when macros from are
>>> used, an
On Thu, Aug 01, 2024 at 05:46:37PM +0200, Jan Beulich wrote:
> This is the simplistic approach; I'm sure this could now be done quite a
> bit more efficiently. I also expect there's no longer a need to run
> ./configure ahead of the invocation of this script, but since I have no
> idea why it was n
On 02.08.2024 11:29, Anthony PERARD wrote:
> As for removing the rule "subtree-force-update-all", I don't think
> that's a good idea at all. As long as Xen's build systems is cloning
> subtrees we need to keep the rule. Those subtrees aren't going away
> anytime soon, especially mini-os for stubdom
On 02.08.2024 10:11, Roger Pau Monné wrote:
> On Fri, Aug 02, 2024 at 02:37:24AM +, Chen, Jiqian wrote:
>> On 2024/7/31 21:03, Roger Pau Monné wrote:
>>> On Wed, Jul 31, 2024 at 01:39:40PM +0200, Jan Beulich wrote:
On 31.07.2024 13:29, Roger Pau Monné wrote:
> On Wed, Jul 31, 2024 at 1
On 02.08.2024 10:08, Roger Pau Monné wrote:
> On Mon, Jul 08, 2024 at 07:41:21PM +0800, Jiqian Chen wrote:
>> Some type of domains don't have PIRQs, like PVH, it doesn't do
>> PHYSDEVOP_map_pirq for each gsi. When passthrough a device
>> to guest base on PVH dom0, callstack
>> pci_add_dm_done->XEN_
Hi,
In the Xen summit, we presented an update on Xen Functional Safety. For
details, please refer to
https://youtu.be/eFRTHSGDMfQ?si=sYOdYfDI7qsgkcjE ("Xen Functional
Safety - an Update - Ayan Kumar Halder & Michal Orzel, AMD")
We wish to start with upstreaming the requirements.
This patches
Added a sample of market, product and design requirements. This is to
help explain how we are writing the requirements and understand the
context of the first patch.
We will be sending these requirements for review in the subsequent
patches.
Please do not merge this patch.
Signed-off-by: Ayan Kum
The FUSA folder is expected to contain requirements and other documents
to enable safety certification of Xen hypervisor.
Added a README to explain how the requirements are categorized, written
and their supported status.
Added maintainers for the same.
Signed-off-by: Ayan Kumar Halder
Acked-by:
Added a guide to help write and review requirements. The requirements
are written to enable safety certification of Xen hypervisor.
Signed-off-by: Ayan Kumar Halder
---
Changes from :-
v1 - 1. No change.
docs/fusa/reqs/REQUIREMENTS-STYLE | 34 +++
1 file changed, 34
On Fri, Aug 02, 2024 at 11:34:53AM +0200, Jan Beulich wrote:
> On 02.08.2024 11:29, Anthony PERARD wrote:
> > As for removing the rule "subtree-force-update-all", I don't think
> > that's a good idea at all. As long as Xen's build systems is cloning
> > subtrees we need to keep the rule. Those subt
Hi Ayan,
> On 2 Aug 2024, at 11:46, Ayan Kumar Halder wrote:
>
> Added a guide to help write and review requirements. The requirements
> are written to enable safety certification of Xen hypervisor.
>
Just a reminder if someone commits this serie:
PATCH 2 MUST NO BE COMMITED !!
Would have bee
flight 187120 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187120/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4f5de749cb2247a4ead21523f2d9deb389291636
baseline version:
ovmf 87d3a6272ca8637787813
On Fri, 2024-08-02 at 11:21 +0200, Jan Beulich wrote:
> On 02.08.2024 11:14, oleksii.kuroc...@gmail.com wrote:
> > On Mon, 2024-07-29 at 15:00 +0200, Jan Beulich wrote:
> > > > To have working BUG(), WARN(), ASSERT,
> > > > run_in_exception_handler()
> > > > it is needed to enable GENERIC_BUG_FRAME
flight 187118 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187118/
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 02.08.2024 12:22, oleksii.kuroc...@gmail.com wrote:
> On Fri, 2024-08-02 at 11:21 +0200, Jan Beulich wrote:
>> On 02.08.2024 11:14, oleksii.kuroc...@gmail.com wrote:
>>> On Mon, 2024-07-29 at 15:00 +0200, Jan Beulich wrote:
> To have working BUG(), WARN(), ASSERT,
> run_in_exception_hand
31.07.24 15:23, Jan Beulich:
On 30.07.2024 12:33, Sergiy Kibrik wrote:
There're several places in common code, outside of arch/x86/hvm/vmx,
where cpu_has_vmx_* get accessed without checking whether VMX supported first.
These macros rely on global variables defined in vmx code, so when VMX suppor
The current logic to chose the preferred reboot method is based on the mode Xen
has been booted into, so if the box is booted from UEFI, the preferred reboot
method will be to use the ResetSystem() run time service call.
However, that method seems to be widely untested, and quite often leads to a
On Fri, 2024-08-02 at 12:30 +0200, Jan Beulich wrote:
> On 02.08.2024 12:22, oleksii.kuroc...@gmail.com wrote:
> > On Fri, 2024-08-02 at 11:21 +0200, Jan Beulich wrote:
> > > On 02.08.2024 11:14, oleksii.kuroc...@gmail.com wrote:
> > > > On Mon, 2024-07-29 at 15:00 +0200, Jan Beulich wrote:
> > > >
On Fri, 2024-08-02 at 12:56 +0200, Roger Pau Monne wrote:
> The current logic to chose the preferred reboot method is based on
> the mode Xen
> has been booted into, so if the box is booted from UEFI, the
> preferred reboot
> method will be to use the ResetSystem() run time service call.
>
> Howev
On 02.08.2024 12:53, Sergiy Kibrik wrote:
> 31.07.24 15:23, Jan Beulich:
>> On 30.07.2024 12:33, Sergiy Kibrik wrote:
>>> There're several places in common code, outside of arch/x86/hvm/vmx,
>>> where cpu_has_vmx_* get accessed without checking whether VMX supported
>>> first.
>>> These macros rel
Delay setting X86_CR4_SMAP on the BSP until the domain building is done, so
that there's no need to disable SMAP. Note however that SMAP is enabled for
the APs on bringup, as domain builder code strictly run on the BSP. Delaying
the setting for the APs would mean having to do a callfunc IPI later
On 02.08.2024 13:02, oleksii.kuroc...@gmail.com wrote:
> There is something what we need is mentioned here:
> https://github.com/riscv-non-isa/riscv-asm-manual/blob/main/riscv-asm.md#instruction-aliases
> But the problem is that is "de-facto" standard, but not really standard
> instruction. Anyway,
On Fri, 2024-08-02 at 13:18 +0200, Jan Beulich wrote:
> On 02.08.2024 13:02, oleksii.kuroc...@gmail.com wrote:
> > There is something what we need is mentioned here:
> > https://github.com/riscv-non-isa/riscv-asm-manual/blob/main/riscv-asm.md#instruction-aliases
> > But the problem is that is "de-f
On Fri, Aug 02, 2024 at 11:40:53AM +0200, Jan Beulich wrote:
> On 02.08.2024 10:08, Roger Pau Monné wrote:
> > On Mon, Jul 08, 2024 at 07:41:21PM +0800, Jiqian Chen wrote:
> >> Some type of domains don't have PIRQs, like PVH, it doesn't do
> >> PHYSDEVOP_map_pirq for each gsi. When passthrough a de
Hi,
In https://patchew.org/Xen/20231116145032.1651305-1-henry.w...@arm.com/, Henry
has
reorganized some of the code between the MMU specific and generic files.
In this patch serie, we address the remaining code reorg so that MMU specific
code is cleanly separated and we have added stubs wherever
From: Penny Zheng
VMAP is widely used in ALTERNATIVE feature, CPUERRATA feature, etc to
remap a range of memory with new memory attributes. Since this is
highly dependent on virtual address translation, we choose to fold VMAP
in MMU system.
In this patch, we introduce a new Kconfig CONFIG_HAS_VM
All the EL2 MMU specific registers are enclosed within CONFIG_MMU.
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/traps.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index aac6c599f8..766aacee77 100644
--- a/xen/arch/arm
This is in continuation to commit
f661a20aa880: "Extract MMU-specific MM code".
update_identity_mapping() is defined for MMU specific logic.
It is invoked from smpboot.c. Thus, we add an empty stub to avoid
if-defery.
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/include/asm/arm64/mm.h | 6
Moved init_domheap_mappings(), map_domain_page_global(),
unmap_domain_page_global(), map_domain_page(), unmap_domain_page(),
domain_page_map_to_mfn() to MMU specific folder.
On the top level, we have added stubs which will invoke the
MMU specific equivalent of these functions.
Signed-off-by: Ayan
On 02.08.2024 14:14, Ayan Kumar Halder wrote:> --- a/xen/include/xen/vmap.h
> +++ b/xen/include/xen/vmap.h
> @@ -138,10 +138,16 @@ static inline void iounmap(void __iomem *va)
> /* Pointer to 1 octet past the end of the VMAP_DEFAULT virtual area */
> void *arch_vmap_virt_end(void);
>
> +#ifdef
flight 187115 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187115/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 186827
test-arm64-arm64-xl
On Fri, Aug 02 2024 at 11:50, Alexey Dobriyan wrote:
Please amend functions with '()' in the subject line and the change log
consistently.
> diff --git a/arch/x86/include/asm/cpuid.h b/arch/x86/include/asm/cpuid.h
> index 6b122a31da06..3eca7824430e 100644
> --- a/arch/x86/include/asm/cpuid.h
> ++
On Fri, Aug 02 2024 at 11:53, Alexey Dobriyan wrote:
> If this memset() is not inlined than PVH early boot code can call
> into KASAN-instrumented memset() which results in unbootable VMs.
>
> Ubuntu's 22.04.4 LTS gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
> doesn't inline this memset but in
flight 187122 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187122/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 24a375fcdd26ce5a36bde69b92f638420fddf9c8
baseline version:
ovmf 4f5de749cb2247a4ead21
Hi Ayan,
On 02/08/2024 13:14, Ayan Kumar Halder wrote:
This is in continuation to commit
f661a20aa880: "Extract MMU-specific MM code".
update_identity_mapping() is defined for MMU specific logic.
It is invoked from smpboot.c. Thus, we add an empty stub to avoid
if-defery.
Signed-off-by: Ayan K
On 2.08.24 г. 11:50 ч., Alexey Dobriyan wrote:
If this memcmp() is not inlined then PVH early boot code can call
into KASAN-instrumented memcmp() which results in unbootable VMs:
pvh_start_xen
xen_prepare_pvh
xen_cpuid_base
hypervisor_cpuid_base
memcmp
Hi,
On 02/08/2024 13:14, Ayan Kumar Halder wrote:
From: Penny Zheng
VMAP is widely used in ALTERNATIVE feature, CPUERRATA feature, etc to
remap a range of memory with new memory attributes. Since this is
highly dependent on virtual address translation, we choose to fold VMAP
in MMU system.
In
On Fri, Aug 02 2024 at 16:25, Nikolay Borisov wrote:
> On 2.08.24 г. 11:50 ч., Alexey Dobriyan wrote:
>> If this memcmp() is not inlined then PVH early boot code can call
>> into KASAN-instrumented memcmp() which results in unbootable VMs:
>>
>> pvh_start_xen
>> xen_prepare_pvh
>> x
Hi,
On 02/08/2024 13:14, Ayan Kumar Halder wrote:
Moved init_domheap_mappings(), map_domain_page_global(),
unmap_domain_page_global(), map_domain_page(), unmap_domain_page(),
domain_page_map_to_mfn() to MMU specific folder.
On the top level, we have added stubs which will invoke the
MMU specifi
Hi,
On 02/08/2024 13:14, Ayan Kumar Halder wrote:
All the EL2 MMU specific registers are enclosed within CONFIG_MMU.
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/traps.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
The patch series provides a basic implementation of exception handling.
It can do only basic things such as decode a cause of an exception,
save/restore registers and execute "wfi" instruction if an exception
can not be handled.
To verify that exception handling works well it was used macros
from
Use array_access_nospec() to prevent guest speculation.
Avoid double access of trap_causes[cause].
Suggested-by: Jan Beulich
Signed-off-by: Oleksii Kurochko
---
Changes in V12:
- New patch.
---
xen/arch/riscv/traps.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/
Introduces testing of some macros from .
Also wraps this testing into SELF_TESTS config to not produce
a noise in the log related to functionality testing ( in the
current case, it is macros from xen/bug.h ) when CONFIG_SELF_TESTS
is disabled.
Signed-off-by: Oleksii Kurochko
Acked-by: Alistair F
Enable GENERIC_BUG_FRAME to support BUG(), WARN(), ASSERT,
and run_in_exception_handler().
The 0x opcode is used for BUG_INSTR, which, when macros from
are used, triggers an exception with the
ILLEGAL_INSTRUCTION cause.
This opcode is encoded as a 2-byte instruction and is invalid if
CONFIG_R
flight 187124 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187124/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f203a6db92eedf03ac544ed270404cb29d3dea7f
baseline version:
ovmf 24a375fcdd26ce5a36bde
flight 187116 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187116/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187103
test-amd64-amd64-xl-qemut-win7-amd64
Non-PCI platform devices may use the ITS. Dom0 Linux drivers for such
devices are failing to register IRQs due to a missing #msi-cells
property. Add the missing #msi-cells property.
Signed-off-by: Stewart Hildebrand
---
See Linux dc4dae00d82f ("Docs: dt: add #msi-cells to GICv3 ITS binding")
---
On Fri, 2 Aug 2024, Ayan Kumar Halder wrote:
> The FUSA folder is expected to contain requirements and other documents
> to enable safety certification of Xen hypervisor.
> Added a README to explain how the requirements are categorized, written
> and their supported status.
>
> Added maintainers f
On Fri, 2 Aug 2024, Stewart Hildebrand wrote:
> Non-PCI platform devices may use the ITS. Dom0 Linux drivers for such
> devices are failing to register IRQs due to a missing #msi-cells
> property. Add the missing #msi-cells property.
>
> Signed-off-by: Stewart Hildebrand
Reviewed-by: Stefano Sta
flight 187121 xen-4.19-testing real [real]
flight 187126 xen-4.19-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187121/
http://logs.test-lab.xenproject.org/osstest/logs/187126/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 187127 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187127/
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 187123 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187123/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 186827
test-arm64-arm64-xl
On 2024-08-02 00:06, Stefano Stabellini wrote:
The ECLAIR jobs part of the Gitlab CI pipeline fail reliably when the
pipeline is started from a merge request. This is the error:
Unexpected event pull_request
The error is a consequence of action.settings setting
event=pull_request
for merge_re
75 matches
Mail list logo
