flight 180917 linux-linus real [real]
flight 180923 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180917/
http://logs.test-lab.xenproject.org/osstest/logs/180923/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Tue, 23 May 2023, Jan Beulich wrote:
> On 23.05.2023 00:20, Stefano Stabellini wrote:
> > On Sat, 20 May 2023, Roger Pau Monné wrote:
> >> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> >> index ec2e978a4e6b..0ff8e940fa8d 100644
> >> --- a/xen/drivers/vpci/header.c
> >>
flight 180918 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180918/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 180478
flight 180913 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180913/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail in 180900 pass in
180913
On 5/23/23 4:37 PM, Arnd Bergmann wrote:
On Sat, May 20, 2023, at 00:24, Boris Ostrovsky wrote:
On 5/19/23 5:28 AM, Arnd Bergmann wrote:
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
index 22fb982ff971..81a7821dd07f 100644
--- a/arch/x86/xen/smp.h
+++ b/arch/x86/xen/smp.h
@@ -1,7
From: Arnd Bergmann
These function are all called from assembler files, or from inline assembler,
so there is no immediate need for a prototype in a header, but if
-Wmissing-prototypes
is enabled, the compiler warns about them:
arch/x86/xen/efi.c:130:13: error: no previous prototype for
On Sat, May 20, 2023, at 00:24, Boris Ostrovsky wrote:
> On 5/19/23 5:28 AM, Arnd Bergmann wrote:
>
>> diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
>> index 22fb982ff971..81a7821dd07f 100644
>> --- a/arch/x86/xen/smp.h
>> +++ b/arch/x86/xen/smp.h
>> @@ -1,7 +1,11 @@
>> /*
On 23/05/2023 5:38 pm, Anthony PERARD wrote:
> CFLAGS is just from Config.mk, instead use the flags used to build
> Xen.
>
> Signed-off-by: Anthony PERARD
> ---
>
> Notes:
> I don't know if CFLAGS is even useful there, just --version without the
> flags might produce the same result.
I
flight 180916 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180916/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 180691
build-amd64-xsm
Stop using the .bdrv_co_io_plug() API because it is not multi-queue
block layer friendly. Use the new blk_io_plug_call() API to batch I/O
submission instead.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
include/block/raw-aio.h | 7 ---
block/file-posix.c | 28
No block driver implements .bdrv_co_io_plug() anymore. Get rid of the
function pointers.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
include/block/block-io.h | 3 ---
include/block/block_int-common.h | 11 --
block/io.c | 37
Stop using the .bdrv_co_io_plug() API because it is not multi-queue
block layer friendly. Use the new blk_io_plug_call() API to batch I/O
submission instead.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
v2
- Add missing #include and fix blkio_unplug_fn() prototype [Stefano]
---
Introduce a new API for thread-local blk_io_plug() that does not
traverse the block graph. The goal is to make blk_io_plug() multi-queue
friendly.
Instead of having block drivers track whether or not we're in a plugged
section, provide an API that allows them to defer a function call until
we're
Stop using the .bdrv_co_io_plug() API because it is not multi-queue
block layer friendly. Use the new blk_io_plug_call() API to batch I/O
submission instead.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
v2
- Remove unused nvme_process_completion_queue_plugged trace event
Stop using the .bdrv_co_io_plug() API because it is not multi-queue
block layer friendly. Use the new blk_io_plug_call() API to batch I/O
submission instead.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
v2
- Removed whitespace hunk [Eric]
---
include/block/raw-aio.h | 7 ---
v2
- Patch 1: "is not be freed" -> "is not freed" [Eric]
- Patch 2: Remove unused nvme_process_completion_queue_plugged trace event
[Stefano]
- Patch 3: Add missing #include and fix blkio_unplug_fn() prototype [Stefano]
- Patch 4: Removed whitespace hunk [Eric]
The existing blk_io_plug() API is
On Tue, May 23, 2023 at 08:43:24AM +0100, Luca Fancellu wrote:
> Add sve parameter in XL configuration to allow guests to use
> SVE feature.
>
> Signed-off-by: Luca Fancellu
Reviewed-by: Anthony PERARD
Thanks,
--
Anthony PERARD
We don't want the AFLAGS from the environment, they are usually meant
to build user space application and not for the hypervisor.
Config.mk doesn't provied any $(AFLAGS) so we can start a fresh
$(XEN_AFLAGS).
Signed-off-by: Anthony PERARD
---
xen/Makefile | 10 ++
The variable $(CFLAGS) is too often set in the environment,
especially when building a package for a distribution. Often, those
CFLAGS are intended to be use to build user spaces binaries, not a
kernel. This mean packager needs to takes extra steps to build Xen by
overriding the CFLAGS provided by
Everything needed to build the hypervisor should already be configured
by "xen/Makefile", thus Config.mk shouldn't be needed.
Then, Config.mk keeps on testing support of some CFLAGS with CC, the
result of this testing is not used at this stage so the build is
slowed unnecessarily.
Likewise, GCC
On Mon, May 22, 2023 at 08:34:52PM +0100, Julien Grall wrote:
> On 19/05/2023 17:24, Anthony PERARD wrote:
> > diff --git a/tools/configure.ac b/tools/configure.ac
> > index 3cccf41960..0f0983f6b7 100644
> > --- a/tools/configure.ac
> > +++ b/tools/configure.ac
> > @@ -517,4 +517,17 @@ AS_IF([test
In xen/, it isn't necessary to include Config.mk in every Makefile in
subdirectories as nearly all necessary variables should be calculated
in xen/Makefile. But some Makefile make use of the macro $(cc-option,)
that is only available in Config.mk.
Extract $(cc-option,) from Config.mk so we can
This is a preparatory patch. A future patch will not even use
$(CFLAGS) to seed $(XEN_CFLAGS).
Signed-off-by: Anthony PERARD
---
xen/Makefile | 41 ++---
xen/arch/arm/arch.mk | 4 +--
xen/arch/riscv/arch.mk | 4 +--
xen/arch/x86/arch.mk | 58
Make the gzip command generic and use -9 which wasn't use for
config.gz. (xen.gz does use -9)
Signed-off-by: Anthony PERARD
---
xen/Rules.mk| 5 +
xen/common/Makefile | 8
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index
CFLAGS is just from Config.mk, instead use the flags used to build
Xen.
Signed-off-by: Anthony PERARD
---
Notes:
I don't know if CFLAGS is even useful there, just --version without the
flags might produce the same result.
xen/build.mk | 2 +-
1 file changed, 1 insertion(+), 1
but still show a log entry for syncconfig. We have to use kecho
instead of $(cmd,) to avoid issue with prompt from kconfig.
linux commits for reference:
23cd88c91343 ("kbuild: hide commands to run Kconfig, and show short log for
syncconfig")
d952cfaf0cff ("kbuild: do not suppress Kconfig
Make use of filechk mean that we don't have to use
$(move-if-changed,). It also mean that will have sometime "UPD .." in
the build output when the target changed, rather than having "GEN ..."
all the time when "xlat.lst" happen to have a more recent modification
timestamp.
While there, replace
Signed-off-by: Anthony PERARD
---
xen/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/Makefile b/xen/Makefile
index e89fc461fc..27f70d2200 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -339,7 +339,7 @@ filechk_kconfig_allconfig = \
:
.allconfig.tmp:
We are adding %.lnk to .PRECIOUS or make treat them as intermediate
targets and remove them.
Signed-off-by: Anthony PERARD
---
xen/arch/x86/boot/Makefile | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
Whether or not the linker can do build id is only used by the
hypervisor build, so move that there.
Rename $(build_id_linker) to $(XEN_LDFLAGS_BUILD_ID) as this is a
better name to be exported as to use the "XEN_*" namespace.
Also update XEN_TREEWIDE_CFLAGS so flags can be used for
Instead, show only when "policy.bin" is been updated.
We still have the full command from the flask/policy Makefile, but we
can't change that Makefile.
Signed-off-by: Anthony PERARD
---
xen/xsm/flask/Makefile | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git
Change of directory to xen/lib/x86 isn't needed to be shown. If
something gets updated, make will print the command line.
Signed-off-by: Anthony PERARD
---
xen/include/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/Makefile b/xen/include/Makefile
index
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.build-system-xen-removing-config.mk-v1
Hi,
This series of patch cleanup the remaining rules still displaying their command
line.
Then, some change are made in Config.mk to remove
Use $(if_changed_dep, ) macro to generate "asm-offsets.s" and remove
the use of $(move-if-changes,). That mean that "asm-offset.s" will be
changed even when the output doesn't change.
But "asm-offsets.s" is only used to generated "asm-offsets.h". So
instead of regenerating "asm-offsets.h" every
flight 180910 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180910/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 180714
test-armhf-armhf-libvirt-raw 15
On Fri, May 19, 2023 at 10:47:00AM +0200, Stefano Garzarella wrote:
> On Wed, May 17, 2023 at 06:10:19PM -0400, Stefan Hajnoczi wrote:
> > Stop using the .bdrv_co_io_plug() API because it is not multi-queue
> > block layer friendly. Use the new blk_io_plug_call() API to batch I/O
> > submission
On Thu, May 18, 2023 at 07:18:42PM -0500, Eric Blake wrote:
> On Wed, May 17, 2023 at 06:10:20PM -0400, Stefan Hajnoczi wrote:
> > Stop using the .bdrv_co_io_plug() API because it is not multi-queue
> > block layer friendly. Use the new blk_io_plug_call() API to batch I/O
> > submission instead.
>
On Thu, May 18, 2023 at 07:04:52PM -0500, Eric Blake wrote:
> On Wed, May 17, 2023 at 06:10:17PM -0400, Stefan Hajnoczi wrote:
> > Introduce a new API for thread-local blk_io_plug() that does not
> > traverse the block graph. The goal is to make blk_io_plug() multi-queue
> > friendly.
> >
> >
On Fri, May 19, 2023 at 10:46:25AM +0200, Stefano Garzarella wrote:
> On Wed, May 17, 2023 at 06:10:18PM -0400, Stefan Hajnoczi wrote:
> > Stop using the .bdrv_co_io_plug() API because it is not multi-queue
> > block layer friendly. Use the new blk_io_plug_call() API to batch I/O
> > submission
On Fri, May 19, 2023 at 10:45:57AM +0200, Stefano Garzarella wrote:
> On Wed, May 17, 2023 at 06:10:17PM -0400, Stefan Hajnoczi wrote:
> > Introduce a new API for thread-local blk_io_plug() that does not
> > traverse the block graph. The goal is to make blk_io_plug() multi-queue
> > friendly.
> >
Since QEMU commit 81e2b198a8cb ("configure: create a python venv
unconditionally"), a python venv is always created and this new package
is needed on Debian.
Signed-off-by: Anthony PERARD
---
ts-xen-build-prep | 1 +
1 file changed, 1 insertion(+)
diff --git a/ts-xen-build-prep
On Tue, May 23, 2023 at 04:03:42PM +0200, Linus Walleij wrote:
> virt_to_page() takes a virtual address as argument but
> the driver passes an unsigned long, which works because
> the target platform(s) uses polymorphic macros to calculate
> the page.
>
> Since many architectures implement
On Tue, May 23, 2023 at 03:54:36PM +0200, Roger Pau Monné wrote:
> On Thu, May 18, 2023 at 04:44:53PM -0700, Stefano Stabellini wrote:
> > Hi all,
> >
> > After many PVH Dom0 suspend/resume cycles we are seeing the following
> > Xen crash (it is random and doesn't reproduce reliably):
> >
> >
virt_to_page() takes a virtual address as argument but
the driver passes an unsigned long, which works because
the target platform(s) uses polymorphic macros to calculate
the page.
Since many architectures implement virt_to_pfn() as
a macro, this function becomes polymorphic and accepts both a
On Thu, May 18, 2023 at 04:44:53PM -0700, Stefano Stabellini wrote:
> Hi all,
>
> After many PVH Dom0 suspend/resume cycles we are seeing the following
> Xen crash (it is random and doesn't reproduce reliably):
>
> (XEN) [555.042981][] R
> arch/x86/irq.c#_clear_irq_vector+0x214/0x2bd
> (XEN)
Hi Daniel,
On 22/05/2023 20:14, Daniel P. Smith wrote:
XSM is a subsystem where it is equally important of how and where its hooks are
called as is the implementation of the hooks. The people best suited for
evaluating the how and where are the XSM maintainers and reviewers. This
creates a
On 23/05/2023 1:37 pm, Jan Beulich wrote:
> There's no real need for the associated probing - we can easily convert
> to a uniform value without knowing the specific behavior (note also that
> the respective comments weren't fully correct and have gone stale).
>
> No difference in generated code.
On 23.05.2023 12:59, Roger Pau Monné wrote:
> On Tue, May 23, 2023 at 08:44:48AM +0200, Jan Beulich wrote:
>> On 23.05.2023 00:20, Stefano Stabellini wrote:
>>> On Sat, 20 May 2023, Roger Pau Monné wrote:
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index
On 23.05.2023 13:57, Luca Fancellu wrote:
>> On 23 May 2023, at 12:53, Jan Beulich wrote:
>> On 23.05.2023 13:50, Luca Fancellu wrote:
On 23 May 2023, at 11:31, Jan Beulich wrote:
On 23.05.2023 12:21, Luca Fancellu wrote:
>> On 23 May 2023, at 11:02, Jan Beulich wrote:
>> On
There's no real need for the associated probing - we can easily convert
to a uniform value without knowing the specific behavior (note also that
the respective comments weren't fully correct and have gone stale).
No difference in generated code.
Signed-off-by: Jan Beulich
---
v2: Use "& 1".
> On 23 May 2023, at 12:53, Jan Beulich wrote:
>
> On 23.05.2023 13:50, Luca Fancellu wrote:
>>> On 23 May 2023, at 11:31, Jan Beulich wrote:
>>> On 23.05.2023 12:21, Luca Fancellu wrote:
> On 23 May 2023, at 11:02, Jan Beulich wrote:
> On 23.05.2023 09:43, Luca Fancellu wrote:
On 23.05.2023 13:50, Luca Fancellu wrote:
>> On 23 May 2023, at 11:31, Jan Beulich wrote:
>> On 23.05.2023 12:21, Luca Fancellu wrote:
On 23 May 2023, at 11:02, Jan Beulich wrote:
On 23.05.2023 09:43, Luca Fancellu wrote:
> @@ -838,6 +838,22 @@ Controls for how dom0 is constructed
> On 23 May 2023, at 11:31, Jan Beulich wrote:
>
> On 23.05.2023 12:21, Luca Fancellu wrote:
>>> On 23 May 2023, at 11:02, Jan Beulich wrote:
>>> On 23.05.2023 09:43, Luca Fancellu wrote:
@@ -838,6 +838,22 @@ Controls for how dom0 is constructed on x86 systems.
If using
Let's have assembler symbols be consistent with C ones. In principle
there are (a few) cases where gas can produce smaller code this way,
just that for now there's a gas bug causing smaller code to be emitted
even when that shouldn't be the case.
Signed-off-by: Jan Beulich
---
v2: New.
---
Recent gas versions generate minimalistic Dwarf debug info for items
annotated as functions and having their sizes specified [1]. "Borrow"
Arm's END() and (remotely) derive other annotation infrastructure from
Linux'es.
For switch_to_kernel() and restore_all_guest() so far implicit alignment
The model introduced in patch 1 is in principle arch-agnostic, hence
why I'm including Arm and RISC-V reviewers here as well.
1: annotate entry points with type and size
2: also mark assembler globals hidden
Jan
On Tue, May 23, 2023 at 08:44:48AM +0200, Jan Beulich wrote:
> On 23.05.2023 00:20, Stefano Stabellini wrote:
> > On Sat, 20 May 2023, Roger Pau Monné wrote:
> >> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> >> index ec2e978a4e6b..0ff8e940fa8d 100644
> >> ---
flight 180907 linux-linus real [real]
flight 180915 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180907/
http://logs.test-lab.xenproject.org/osstest/logs/180915/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Hi Jan,
> -Original Message-
> On 23.05.2023 09:32, Henry Wang wrote:
> > By looking into the existing implementation of NUMA for DT,
> > in Linux, from drivers/base/arch_numa.c: numa_set_distance(), there is a
> > "if ((u8)distance != distance)" then return. So I think at least in Linux
On 23.05.2023 12:21, Luca Fancellu wrote:
>> On 23 May 2023, at 11:02, Jan Beulich wrote:
>> On 23.05.2023 09:43, Luca Fancellu wrote:
>>> @@ -838,6 +838,22 @@ Controls for how dom0 is constructed on x86 systems.
>>>
>>> If using this option is necessary to fix an issue, please report a bug.
> On 23 May 2023, at 11:02, Jan Beulich wrote:
>
> On 23.05.2023 09:43, Luca Fancellu wrote:
>> Add a command line parameter to allow Dom0 the use of SVE resources,
>> the command line parameter sve=, sub argument of dom0=,
>> controls the feature on this domain and sets the maximum SVE vector
On Tue, May 23, 2023 at 01:12:26AM +0200, Thomas Gleixner wrote:
> Let me find a brown paperbag and go to sleep before I even try to
> compile the obvious fix.
That fixes the problem on TX2 - thanks!
Tested-by: Mark Brown
signature.asc
Description: PGP signature
flight 180912 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180912/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 180691
build-amd64-xsm
On 23.05.2023 09:32, Henry Wang wrote:
>> -Original Message-
>> Subject: Re: [PATCH v4 09/17] xen/arm: introduce a helper to parse device
>> tree NUMA distance map
>>
>> The [2] link you provided discusses NUMA_LOCAL_DISTANCE.
>
> I inferred the discussion as "we should try to
On 23.05.2023 09:43, Luca Fancellu wrote:
> Add a command line parameter to allow Dom0 the use of SVE resources,
> the command line parameter sve=, sub argument of dom0=,
> controls the feature on this domain and sets the maximum SVE vector
> length for Dom0.
>
> Add a new function,
Arm now can use the "dom0=" Xen command line option and the support
for guests running SVE instructions is added, put entries in the
changelog.
Mention the "Tech Preview" status and add an entry in SUPPORT.md
Signed-off-by: Luca Fancellu
Acked-by: Henry Wang # CHANGELOG
---
Changes from v6:
-
Add a device tree property in the dom0less domU configuration
to enable the guest to use SVE.
Update documentation.
Signed-off-by: Luca Fancellu
---
Changes from v6:
- Use ifdef in create_domUs and fail if 'sve' is used on systems
with CONFIG_ARM64_SVE not selected (Bertrand, Julien, Jan)
On Arm, the SVE vector length is encoded in arch_capabilities field
of struct xen_sysctl_physinfo, make use of this field in the tools
when building for arm.
Create header arm-arch-capabilities.h to handle the arch_capabilities
field of physinfo for Arm.
Removed include for
Add sve parameter in XL configuration to allow guests to use
SVE feature.
Signed-off-by: Luca Fancellu
---
Changes from v6:
- Add check for sve_vl be multiple of 128 (Anthony)
Changes from v5:
- Update documentation
- re-generated golang files
Changes from v4:
- Rename sve field to sve_vl
Currently x86 defines a Xen command line argument dom0= where
there can be specified dom0 controlling sub-options, to use it also
on Arm, move the code that loops through the list of arguments from
x86 to the common code and from there, call architecture specific
functions to handle the comma
SVE has a new exception class with code 0x19, introduce the new code
and handle the exception.
Signed-off-by: Luca Fancellu
Reviewed-by: Bertrand Marquis
Reviewed-by: Julien Grall
---
Changes from v6:
- Add R-by Julien
Changes from v5:
- modified error messages (Julien)
- add R-by Bertrand
Save/restore context switch for SVE, allocate memory to contain
the Z0-31 registers whose length is maximum 2048 bits each and
FFR who can be maximum 256 bits, the allocated memory depends on
how many bits is the vector length for the domain and how many bits
are supported by the platform.
Save
When the arm platform supports SVE, advertise the feature in the
field arch_capabilities in struct xen_sysctl_physinfo by encoding
the SVE vector length in it.
Signed-off-by: Luca Fancellu
Reviewed-by: Bertrand Marquis
---
Changes from v6:
- no changes
Changes from v5:
- Add R-by from
Add a command line parameter to allow Dom0 the use of SVE resources,
the command line parameter sve=, sub argument of dom0=,
controls the feature on this domain and sets the maximum SVE vector
length for Dom0.
Add a new function, parse_signed_integer(), to parse an integer
command line argument.
This serie is introducing the possibility for Dom0 and DomU guests to use
sve/sve2 instructions.
SVE feature introduces new instruction and registers to improve performances on
floating point operations.
The SVE feature is advertised using the ID_AA64PFR0_EL1 register, SVE field, and
when
Enable Xen to handle the SVE extension, add code in cpufeature module
to handle ZCR SVE register, disable trapping SVE feature on system
boot only when SVE resources are accessed.
While there, correct coding style for the comment on coprocessor
trapping.
Now cptr_el2 is part of the domain context
When a guest is allowed to use SVE, expose the SVE features through
the identification registers.
Signed-off-by: Luca Fancellu
Acked-by: Julien Grall
---
Changes from v6:
- code style fix, add A-by Julien
Changes from v5:
- given the move of is_sve_domain() in asm/arm64/sve.h, add the
Add sve_vl field to arch_domain and xen_arch_domainconfig struct,
to allow the domain to have an information about the SVE feature
and the number of SVE register bits that are allowed for this
domain.
sve_vl field is the vector length in bits divided by 128, this
allows to use less space in the
Hi Jan,
> -Original Message-
> Subject: Re: [PATCH v4 09/17] xen/arm: introduce a helper to parse device
> tree NUMA distance map
>
> The [2] link you provided discusses NUMA_LOCAL_DISTANCE.
> >>>
> >>> I inferred the discussion as "we should try to keep consistent between the
> >>
flight 180900 xen-unstable real [real]
flight 180911 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180900/
http://logs.test-lab.xenproject.org/osstest/logs/180911/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 22.05.2023 17:49, Anthony PERARD wrote:
> On Mon, May 08, 2023 at 08:23:43AM +0200, Jan Beulich wrote:
>> On 05.05.2023 18:08, Anthony PERARD wrote:
>>> On Wed, Mar 15, 2023 at 03:58:59PM +0100, Jan Beulich wrote:
With in-tree builds Config.mk includes a .config file (if present) from
On 23.05.2023 00:20, Stefano Stabellini wrote:
> On Sat, 20 May 2023, Roger Pau Monné wrote:
>> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
>> index ec2e978a4e6b..0ff8e940fa8d 100644
>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -289,6 +289,13
On 23.05.2023 08:31, Henry Wang wrote:
>> -Original Message-
>> Subject: Re: [PATCH v4 09/17] xen/arm: introduce a helper to parse device
>> tree NUMA distance map
>>
>>> +/* The default value in node_distance_map is
NUMA_NO_DISTANCE
>> */
>>> +if (
On 22.05.2023 18:25, Andrew Cooper wrote:
> On 03/04/2023 3:56 pm, Jan Beulich wrote:
>> While I (quite obviously) don't have any suitable hardware, Intel's
>> SDE allows testing the implementation. And since there's no new
>> state (registers) associated with this ISA extension, this should
>>
On Thu, May 18, 2023 at 4:35 PM Anthony PERARD
wrote:
>
> On Thu, Apr 13, 2023 at 09:14:05AM +0200, Jens Wiklander wrote:
> > Adds a new "ffa" value to the Enumeration "tee_type" to indicate if a
> > guest is trusted to use FF-A.
>
> Is "ffa" working yet in the hypervisor? (At this point in the
Hi Jan,
> -Original Message-
> Subject: Re: [PATCH v4 09/17] xen/arm: introduce a helper to parse device
> tree NUMA distance map
>
> > +/* The default value in node_distance_map is
> >> NUMA_NO_DISTANCE
> */
> > +if ( opposite == NUMA_NO_DISTANCE )
>
>
86 matches
Mail list logo
