On 22.02.23 18:54, Krister Johansen wrote:
Hi,
Enclosed please find a pair of patches that perform some additional cleanup
that was suggested by Boris, Jan and Thomas.
Specifically: this resync's arch/x86/include/asm/xen/cpuid.h from its
upstream source in the Xen tree, and then uses one of the
We are doing foreign memory mapping for static shared memory, and
there is a great possibility that it could be super mapped.
But today, p2m_put_l3_page could not handle superpages.
This commits implements a new function p2m_put_superpage to handle superpages,
specifically for helping put extra
This commit amends docs(docs/misc/arm/device-tree/booting.txt) to include the
new scenario where host address is not provided in "xen,shared-mem" property,
and we also add a new example to explain in detail.
We also fix some buggy info in the docs, like SHMID is "my-shared-mem-1",
not "0x1".
In order to support static shared memory when host address not provided,
we shall do the following modification:
- we shall let Xen allocate memory from heap for static shared memory
at first domain, no matter it is owner or borrower.
- In acquire_shared_memory_bank, as static shared memory has
Static shared memory acts as reserved memory in guest, so it shall be
excluded from extended regions.
Extended regions are taken care of under three different scenarios:
normal DomU, direct-map domain with iommu on, and direct-map domain
with iommu off.
For normal DomU, we create a new function
We use paddr_assigned to indicate whether host address is provided, by
checking the length of "xen,shared-mem" property.
The shm matching criteria shall also be adapt to cover the new scenario, by
adding when host address is not provided, if SHMID matches, the region size
must exactly match too.
We split the code of allocate_bank_memory into two parts,
allocate_domheap_memory and guest_physmap_memory.
One is about allocating guest RAM from heap, which could be re-used later for
allocating static shared memory from heap when host address is not provided.
The other is building up guest P2M
This commit introduces a set of separate data structures to deal with
static shared memory at different stages.
In boot-time host device tree parsing, we introduce a new structure
"struct shm_node" and a new field "shm_info" in bootinfo to describe and
store parsed shm info.
only SHMID and
There are some unsolving issues on current 4.17 static shared memory
feature[1], including:
- In order to avoid keeping growing 'membank', having the shared memory
info in separate structures is preferred.
- Missing implementation on having the host address optional in
"xen,shared-mem" property
-
Function parameters {addr_cells,size_cells} are stale parameters in
assign_shared_memory, so we shall remove them.
Signed-off-by: Penny Zheng
---
v1 -> v2:
- new commit
---
xen/arch/arm/domain_build.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c
flight 178137 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178137/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 174778
flight 178138 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178138/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 177405
flight 178136 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178136/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 broken
flight 178125 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178125/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-install fail like 176460
test-amd64-amd64-qemuu-nested-amd 20
To quote Andrew Cooper:
> I know we've had this argument before, but not calling
> SetVirtualAddressMap() isn't a viable option. It's a prerequisite to
> function on literally millions of devices
Qubes OS has been shipping EFI_SET_VIRTUAL_ADDRESS_MAP for years, and I
believe OpenXT and EVE ship
flight 178107 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178107/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-examine-bios 4 memdisk-try-append fail blocked in 178070
flight 178146 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178146/
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
Modifies xen_tsc_safe_clocksource() to use newly defined constants from
arch/x86/include/asm/xen/cpuid.h. This replaces a numeric value with
XEN_CPUID_TSC_MODE_NEVER_EMULATE, and deletes a comment that is now self
explanatory.
There should be no change in the function's behavior.
Signed-off-by:
Update arch/x86/include/asm/xen/cpuid.h from the Xen tree to get newest
definitions. This picks up some TSC mode definitions and comment
formatting changes.
Signed-off-by: Krister Johansen
---
arch/x86/include/asm/xen/cpuid.h | 22 ++
1 file changed, 18 insertions(+), 4
Hi,
Enclosed please find a pair of patches that perform some additional cleanup
that was suggested by Boris, Jan and Thomas.
Specifically: this resync's arch/x86/include/asm/xen/cpuid.h from its
upstream source in the Xen tree, and then uses one of the new #define-s to
replace a constant in
On 22.02.2023 17:20, Andrew Cooper wrote:
> On 22/02/2023 4:17 pm, Jan Beulich wrote:
>> On 22.02.2023 17:04, Andrew Cooper wrote:
>>> While testing the rebuilt debian unstable container, I found:
>>>
>>> common/core_parking.c: In function 'core_parking_remove':
>>> common/core_parking.c:230:53:
On 22/02/2023 4:17 pm, Jan Beulich wrote:
> On 22.02.2023 17:04, Andrew Cooper wrote:
>> While testing the rebuilt debian unstable container, I found:
>>
>> common/core_parking.c: In function 'core_parking_remove':
>> common/core_parking.c:230:53: error: array subscript 1 is above array
>> bounds
On 22.02.2023 17:04, Andrew Cooper wrote:
> While testing the rebuilt debian unstable container, I found:
>
> common/core_parking.c: In function 'core_parking_remove':
> common/core_parking.c:230:53: error: array subscript 1 is above array
> bounds of 'unsigned int[1]' [-Werror=array-bounds]
>
Hello Jan,
On Wed, 2023-02-22 at 13:46 +0100, Jan Beulich wrote:
> On 20.02.2023 17:40, Oleksii Kurochko wrote:
> > A large part of the content of the bug.h is repeated among all
> > architectures, so it was decided to create a new config
> > CONFIG_GENERIC_BUG_FRAME.
> >
> > The version of
While testing the rebuilt debian unstable container, I found:
common/core_parking.c: In function 'core_parking_remove':
common/core_parking.c:230:53: error: array subscript 1 is above array
bounds of 'unsigned int[1]' [-Werror=array-bounds]
230 | core_parking_cpunum[i] =
flight 178114 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178114/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 8 xen-boot fail REGR. vs. 178042
Adds support to reclaim memory previously shared with FFA_MEM_SHARE.
Adds a check that the SP supports the needed FF-A feature
FFA_MEM_RECLAIM.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 53 ++
1 file changed, 53 insertions(+)
diff --git
Adds support for sharing large memory ranges transmitted in fragments
using FFA_MEM_FRAG_TX.
The implementation is the bare minimum to be able to communicate with
OP-TEE running as an SPMC at S-EL1.
Adds a check that the SP supports the needed FF-A feature
FFA_MEM_FRAG_TX.
Signed-off-by: Jens
Adds the ABI structs used by function FFA_MEM_SHARE and friends for
sharing memory.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 74 ++
1 file changed, 74 insertions(+)
diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index
Adds defines needed for sharing using the function FFA_MEM_SHARE and
friends.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 57 ++
1 file changed, 57 insertions(+)
diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index
Adds support for a guest to share memory with an SP using FFA_MEM_SHARE
and FFA_MEM_RECLAIM. Only small memory regions can be shared using a
single call to FFA_MEM_SHARE are supported.
A memory region that doesn't need to be shared any longer can be
reclaimed with FFA_MEM_RECLAIM once the SP
Adds a FF-A version 1.1 [1] mediator to communicate with a Secure
Partition in secure world.
This commit brings in only the parts needed to negotiate FF-A version
number with guest and SPMC.
[1] https://developer.arm.com/documentation/den0077/e
Signed-off-by: Jens Wiklander
---
Moves the two helper functions regpair_to_uint64() and
uint64_to_regpair() from xen/arch/arm/tee/optee.c to the common arm
specific regs.h. This enables reuse of these functions in the FF-A
mediator in a subsequent patch.
Reviewed-by: Michal Orzel
Signed-off-by: Jens Wiklander
---
Adds support for the FF-A function FFA_ID_GET to return the ID of the
calling client.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index
Adds support in the mediator to handle FFA_PARTITION_INFO_GET requests
from a guest. The requests are forwarded to the SPMC and the response is
translated according to the FF-A version in use by the guest.
Using FFA_PARTITION_INFO_GET changes the owner of the RX buffer to the
caller (the guest in
The FF-A specification defines framework messages sent as direct
requests when certain events occurs. For instance when a VM (guest) is
created or destroyed. Only SPs which have subscribed to these events
will receive them. An SP can subscribe to these messages in its
partition properties.
Adds a
Adds support for sending a FF-A direct request. Checks that the SP also
supports handling a 32-bit direct request. 64-bit direct requests are
not used by the mediator itself so there is not need to check for that.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 119
Adds support in the mediator to map and unmap the RX and TX buffers
provided by the guest using the two FF-A functions FFA_RXTX_MAP and
FFA_RXTX_UNMAP.
These buffer are later used to to transmit data that cannot be passed in
registers only.
Signed-off-by: Jens Wiklander
---
When initializing the FF-A mediator map the RX and TX buffers shared with
the SPMC.
These buffer are later used to to transmit data that cannot be passed in
registers only.
Adds a check that the SP supports the needed FF-A features
FFA_RXTX_MAP_64 / FFA_RXTX_MAP_32 and FFA_RXTX_UNMAP. In 64-bit
SMCCC v1.2 [1] AArch64 allows x0-x17 to be used as both parameter
registers and result registers for the SMC and HVC instructions.
Arm Firmware Framework for Armv8-A specification makes use of x0-x7 as
parameter and result registers.
Let us add new interface to support this extended set of
Adds defines for framework direct request/response messages.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index f4562ed2defc..d04bac9cc47f 100644
--- a/xen/arch/arm/tee/ffa.c
Describes a FF-A version 1.1 [1] mediator to communicate with a Secure
Partition in secure world.
[1] https://developer.arm.com/documentation/den0077/latest
Signed-off-by: Jens Wiklander
---
SUPPORT.md | 7 +++
docs/man/xl.cfg.5.pod.in | 15 +++
2 files changed,
Adds a BUILD_BUG_ON() to assert the dependency on 4k pages in the FF-A
mediator.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index d04bac9cc47f..8b0b80ce1ff5
Defines flags used for the function FFA_PARTITION_INFO_GET.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index aa6cdbe0a4f9..f4562ed2defc 100644
---
Adds a new "ffa" value to the Enumeration "tee_type" to indicate if a
guest is trusted to use FF-A.
Signed-off-by: Jens Wiklander
---
tools/libs/light/libxl_arm.c | 3 +++
tools/libs/light/libxl_types.idl | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git
Adds the remaining SMC function IDs from FF-A 1.1 specification.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 824153c9303a..aa6cdbe0a4f9
Hi,
This patch sets add an FF-A [1] mediator to the TEE mediator framework
already present in Xen. The FF-A mediator implements the subset of the
FF-A 1.1 specification needed to communicate with OP-TEE using FF-A as
transport mechanism instead of SMC/HVC as with the TEE mediator. It allows
a
flight 178129 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178129/
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
Hi Andrew,
On 22/02/2023 15:13, Andrew Cooper wrote:
>
>
> Xen 4.13 is fully out of support now. Drop this legacy build dependency.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Michal Orzel
~Michal
On Wed, Feb 22, 2023 at 5:48 AM Jan Beulich wrote:
>
> On 21.02.2023 16:59, Tamas K Lengyel wrote:
> > On Tue, Feb 21, 2023 at 8:54 AM Jan Beulich wrote:
> >>
> >> On 15.02.2023 18:07, Tamas K Lengyel wrote:
> >>> An assert failure has been observed in p2m_teardown when performing vm
> >>>
Xen 4.13 is fully out of support now. Drop this legacy build dependency.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Stefano Stabellini
CC: Michal Orzel
CC: Doug Goldstein
---
automation/build/alpine/3.12-arm64v8.dockerfile | 2 --
On 22.02.2023 13:00, Xenia Ragiadakou wrote:
> Remove forward declaration of struct vcpu, that is a leftover since
> the removal of svm_update_guest_cr()'s declaration from svm.h.
>
> Signed-off-by: Xenia Ragiadakou
Acked-by: Jan Beulich
> Fixes: b158e72abe30 ("x86/hvm: CFI hardening for
On 20.02.2023 17:40, Oleksii Kurochko wrote:
> A large part of the content of the bug.h is repeated among all
> architectures, so it was decided to create a new config
> CONFIG_GENERIC_BUG_FRAME.
>
> The version of from x86 was taken as the base version.
>
> The patch introduces the following
On 21/02/2023 13:43, Jan Beulich wrote:
On 09.02.2023 11:38, Jan Beulich wrote:
This is the only file left with a use of an __s type coming from
Linux. Since the file has been using an apparently random mix of all
three classes of fixed-width types (__{s,u}, {s,u}, and
{,u}int_t), consolidate
flight 178089 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178089/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass
test-amd64-i386-libvirt 15
Reduce the scope of nvmx_enqueue_n2_exceptions() to static because it is used
only in this file.
Take the opportunity to remove a trailing space.
Signed-off-by: Xenia Ragiadakou
---
Changes in v2:
- none
xen/arch/x86/hvm/vmx/vmx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Move vmx_update_debug_state() in vmcs.c because it is used only in this
file and limit its scope to this file by declaring it static and removing
its declaration from private vmx.h
Signed-off-by: Xenia Ragiadakou
---
Changes in v2:
- remove it from the private vmx.h header instead of the
Create a new private header in arch/x86/hvm/vmx/ called vmx.h and move there
all definitions and declarations that are used solely by vmx code.
EPT related declarations and definitions stay in asm/hvm/vmx/vmx.h because
they are used in arch/x86/mm and drivers/passthrough/vtd.
Also, __vmread(),
Since GAS_VMX_OP is used only by vm{read,write}_safe, move its definition
just above those functions and undefine it after use.
Signed-off-by: Xenia Ragiadakou
---
Changes in v2:
- none
xen/arch/x86/include/asm/hvm/vmx/vmx.h | 14 --
1 file changed, 8 insertions(+), 6
Do not include the headers:
asm/hvm/vpic.h
asm/hvm/vpt.h
asm/io.h
asm/mce.h
asm/mem_sharing.h
asm/regs.h
public/arch-x86/cpuid.h
public/hvm/save.h
because none of the declarations and macro definitions in them is used.
Sort the rest of the headers alphabetically.
Signed-off-by:
Remove forward declaration of struct vcpu, that is a leftover since
the removal of svm_update_guest_cr()'s declaration from svm.h.
Signed-off-by: Xenia Ragiadakou
Fixes: b158e72abe30 ("x86/hvm: CFI hardening for hvm_funcs")
---
Changes in v2:
- leave the forward declaration of struct
Delete the macros SVM_PAUSE{FILTER,THRESH}_INIT from svm.h and opencode
their values, since they are used in a single place and using macros is
just unnecessary obfuscation.
Signed-off-by: Xenia Ragiadakou
---
Changes in v2:
- opencode instead of moving the macros in vmcs.c, suggested by
Do not include the headers:
asm/i387.h
asm/hvm/trace.h
asm/processor.h
asm/regs.h
because none of the declarations and macro definitions in them is used in
this file. Sort the rest of the headers alphabetically.
Fix build by including asm/i387.h in vmx.c, needed for
This patch series attempts a cleanup of files {svm,vmx}.{c,h} by removing
redundant headers and sorting the rest, reducing the scope of declarations
and definitions, moving functions used only by internal {svm,vmx} code to
private headers.
This series aims to address the comments made on the
Create a new private header in arch/x86/hvm/svm called svm.h and move there
all definitions and declarations that are used solely by svm code.
The function svm_invlpga() stays in arch/x86/hvm/svm/svm.h because it is used
by arch/x86/hvm/svm/asid.h.
Signed-off-by: Xenia Ragiadakou
---
Changes
On 22.02.2023 12:15, Andrew Cooper wrote:
> On 22/02/2023 10:22 am, Jan Beulich wrote:
>> In COVERAGE=y but DEBUG=n builds (observed by randconfig testing) gcc12
>> takes issue with the subtraction of 1 from __stop___pre_ex_table[],
>> considering this an out of bounds access. Not being able to
On 22/02/2023 10:22 am, Jan Beulich wrote:
> In COVERAGE=y but DEBUG=n builds (observed by randconfig testing) gcc12
> takes issue with the subtraction of 1 from __stop___pre_ex_table[],
> considering this an out of bounds access. Not being able to know that
> the symbol actually marks the end of
On 22/02/2023 10:35 am, Jan Beulich wrote:
> The attribute has no purpose here and, in the worst case, could lead to
> the compiler generating worse code. In practice, however: No change to
> generated code (surprisingly not even to generated debug info), at least
> with gcc12 and the .config-s
On 21.02.2023 16:59, Tamas K Lengyel wrote:
> On Tue, Feb 21, 2023 at 8:54 AM Jan Beulich wrote:
>>
>> On 15.02.2023 18:07, Tamas K Lengyel wrote:
>>> An assert failure has been observed in p2m_teardown when performing vm
>>> forking and then destroying the forked VM (p2m-basic.c:173). The assert
On 21.02.2023 22:26, Sergey Dyasli wrote:
> On Tue, Feb 21, 2023 at 2:03 PM Jan Beulich wrote:
>>
>> On 15.02.2023 16:38, Sergey Dyasli wrote:
>>> --- a/xen/arch/x86/cpu/microcode/core.c
>>> +++ b/xen/arch/x86/cpu/microcode/core.c
>>> @@ -398,10 +398,16 @@ static int cf_check
The attribute has no purpose here and, in the worst case, could lead to
the compiler generating worse code. In practice, however: No change to
generated code (surprisingly not even to generated debug info), at least
with gcc12 and the .config-s I've tried.
Requested-by: Andrew Cooper
In COVERAGE=y but DEBUG=n builds (observed by randconfig testing) gcc12
takes issue with the subtraction of 1 from __stop___pre_ex_table[],
considering this an out of bounds access. Not being able to know that
the symbol actually marks the end of an array, the compiler is kind of
right with this
On 22/02/2023 9:53 am, Jan Beulich wrote:
> On 22.02.2023 10:42, Jan Beulich wrote:
>> On 21.02.2023 19:05, Andrew Cooper wrote:
>>> On 21/02/2023 4:55 pm, Anthony PERARD wrote:
Building randconfig on debian unstable seems to be an issue.
>>> You're talking about
>>>
On 22.02.2023 10:42, Jan Beulich wrote:
> On 21.02.2023 19:05, Andrew Cooper wrote:
>> On 21/02/2023 4:55 pm, Anthony PERARD wrote:
>>> Building randconfig on debian unstable seems to be an issue.
>>
>> You're talking about
>> https://gitlab.com/xen-project/people/anthonyper/xen/-/jobs/3769926509
On 21.02.2023 19:05, Andrew Cooper wrote:
> On 21/02/2023 4:55 pm, Anthony PERARD wrote:
>> Building randconfig on debian unstable seems to be an issue.
>
> You're talking about
> https://gitlab.com/xen-project/people/anthonyper/xen/-/jobs/3769926509 ?
>
> + gcc --version
> gcc (Debian
On 22.02.23 09:52, Julien Grall wrote:
Hi Juergen,
On 22/02/2023 08:36, Juergen Gross wrote:
On 21.02.23 23:36, Julien Grall wrote:
Hi Juergen,
On 21/02/2023 08:10, Juergen Gross wrote:
On 20.02.23 19:01, Julien Grall wrote:
So I have recreated an XTF test which I think match what you
On 21.02.2023 19:14, Andrew Cooper wrote:
> On 21/02/2023 1:40 pm, Jan Beulich wrote:
>> On 20.02.2023 20:47, Andrew Cooper wrote:
>>> Despite its name, the irq{save,restore}() APIs are only intended to
>>> conditionally disable and re-enable interrupts.
>> Are they?
>
> Yes, absolutely.
>
> And
flight 178093 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178093/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-coresched-amd64-xl broken
test-amd64-coresched-amd64-xl 5
Hi Juergen,
On 22/02/2023 08:36, Juergen Gross wrote:
On 21.02.23 23:36, Julien Grall wrote:
Hi Juergen,
On 21/02/2023 08:10, Juergen Gross wrote:
On 20.02.23 19:01, Julien Grall wrote:
So I have recreated an XTF test which I think match what you wrote [1].
It is indeed failing without
On 21.02.23 23:42, Julien Grall wrote:
Hi Juergen,
On 21/02/2023 08:37, Juergen Gross wrote:
On 20.02.23 23:50, Julien Grall wrote:
+ list_del(>list);
+ talloc_free(cd);
+ }
+}
+
+void acc_commit(struct connection *conn)
+{
+ struct changed_domain *cd;
+ struct
On 21.02.23 23:36, Julien Grall wrote:
Hi Juergen,
On 21/02/2023 08:10, Juergen Gross wrote:
On 20.02.23 19:01, Julien Grall wrote:
So I have recreated an XTF test which I think match what you wrote [1].
It is indeed failing without your patch. But then there are still some weird
behavior
flight 178070 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178070/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 177972
test-amd64-i386-xl-qemuu-win7-amd64
82 matches
Mail list logo
