flight 186895 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186895/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 186826
test-amd64-a
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 186878 xen-4.19-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186878/
Failures :-/
flight 186892 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186892/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 186826
test-amd64-a
On older systems, XHCI xcap had a layout that no other (interesting) registers
were placed on the same page as the debug capability, so Linux was fine with
making the whole page R/O. But at least on Tiger Lake and Alder Lake, Linux
needs to write to some other registers on the same page too.
Add a
In some cases, only few registers on a page needs to be write-protected.
Examples include USB3 console (64 bytes worth of registers) or MSI-X's
PBA table (which doesn't need to span the whole table either), although
in the latter case the spec forbids placing other registers on the same
page. Curre
Not the whole page, which may contain other registers too. The XHCI
specification describes DbC as designed to be controlled by a different
driver, but does not mandate placing registers on a separate page. In fact
on Tiger Lake and newer (at least), this page do contain other registers
that Linux
Similar to LIST_HEAD_READ_MOSTLY.
Signed-off-by: Marek Marczykowski-Górecki
---
New in v5
---
xen/include/xen/list.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/include/xen/list.h b/xen/include/xen/list.h
index 6506ac40893b..62169f46742e 100644
--- a/xen/include/xen/list.h
+++ b/x
flight 186885 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186885/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 186826
test-amd64-a
flight 186877 linux-6.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186877/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186804
test-amd64-amd64-xl-qemuu-win7-amd64 19
flight 186883 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186883/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 186826
test-amd64-a
On Thu, 18 Jul 2024, Jan Beulich wrote:
> On 18.07.2024 01:02, Stefano Stabellini wrote:
> > On Wed, 17 Jul 2024, Jan Beulich wrote:
> >> On 17.07.2024 02:20, Stefano Stabellini wrote:
> >>> On Tue, 16 Jul 2024, Jan Beulich wrote:
> On 16.07.2024 02:43, Stefano Stabellini wrote:
> > On Mon
The idle domain needs d->arch.ctxt_switch initialised on x86. Implement the
new arch_init_idle_domain() in order to do this.
Right now this double-initalises the ctxt_switch pointer, but it's safe and
will stop happening when domain_create() is cleaned up as a consequence.
No practical change.
With arch_domain_create() no longer being called with the idle domain, drop
the last remaining logic.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orz
domain_create() has some unnecessary complexity for constructing the idle
domain. Rearrange x86's needs, to simplify the common logic.
https://cirrus-ci.com/build/5234584097390592
https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1379531597
Andrew Cooper (4):
xen/domain: Introduce
With x86 implementing arch_init_idle_domain(), there is no longer any need to
call arch_domain_create() with the idle domain.
Have the idle domain exit early with all other system domains. Move the
static-analysis ASSERT() earlier. Then, remove the !is_idle_domain()
protections around the majori
The idle domain causes a large amount of complexity in domain_create() because
of x86's need to initialise d->arch.ctxt_switch in arch_domain_create().
In order to address this, introduce an optional hook to perform extra
initialisation of the idle domain.
No functional change.
Signed-off-by: An
On 7/18/24 2:21 AM, Juergen Gross wrote:
The recent adding of multicall debug mixed up the referencing of
the debug data. A __percpu tagged pointer can't be initialized with a
plain pointer, so use another percpu variable for the pointer and set
it on each new cpu via a function.
Fixes: 942d91
flight 186881 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186881/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 489e4a60ea88326a07a7cee8086227c3df2bf93d
baseline version:
ovmf 62bf2aefc7d58288bb9e3
flight 186880 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186880/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 186826
test-amd64-a
flight 186876 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186876/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl 8 xen-boot fail in 186850 pass in 186876
test-armhf-armhf-xl-credit2
On Wed Jul 17, 2024 at 4:51 PM BST, Teddy Astie wrote:
> If for some reason, xmalloc fails after having mapped the
> reserved regions, a error is reported, but the regions are
> actually mapped in p2m.
>
> Move the allocation before trying to map the regions, in
> case the allocation fails, no mapp
On Tue Jun 25, 2024 at 11:47 PM BST, Tamas K Lengyel wrote:
> The build integration script for oss-fuzz targets. Future fuzzing targets can
> be added to this script and those targets will be automatically picked up by
> oss-fuzz without having to open separate PRs on the oss-fuzz repo.
>
> Signed-
On Thu Jul 18, 2024 at 1:19 PM BST, Jan Beulich wrote:
> On 09.07.2024 17:52, Alejandro Vallejo wrote:
> > It's doing too many things at once and there's no clear way of defining what
> > it's meant to do. This patch splits the function in two.
> >
> > 1. A reset function, parameterized by the F
On 18/07/2024 11:10 am, Jan Beulich wrote:
> Therefore with SHADOW_PAGING=n this is better compiled out, to avoid
> leaving around unreachable/dead code.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -271,6 +271,8 @@ int mtrr_get_type(const s
On Thu Jul 18, 2024 at 12:49 PM BST, Jan Beulich wrote:
> On 09.07.2024 17:52, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/domctl.c
> > +++ b/xen/arch/x86/domctl.c
> > @@ -1343,7 +1343,8 @@ void arch_get_info_guest(struct vcpu *v,
> > vcpu_guest_context_u c)
> > #define c(fld) (c.nat->fld)
>
With the input data now conveniently arranged, use writev()/sendmsg() instead
of decomposing it into write() calls.
This causes all requests to be submitted with a single system call, rather
than at least two. While in principle short writes can occur, the chances of
it happening are slim given t
We would like to writev() the whole outgoing message, which is hard given the
current need to prepend the locally-constructed xsd_sockmsg.
Instead, have the caller provide xsd_sockmsg in iovec[0]. This in turn drops
the t and type parameters from xs_talkv().
Note that xs_talkv() may alter the io
While the purpose of this series is patch 6, it has a side effect of reducing
the number of system calls substantally.
Using a strace of test-xenstore as an example, we go from this:
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER,
sa_restorer=0x7fda8278e2f0}, {sa_h
It will determine whether to use writev() or sendmsg().
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Juergen Gross
---
tools/libs/store/xs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/libs/store/xs.c b/tools/libs/store/xs.c
index 96ea2b192924..f4edeb05f03b 100644
It's very rude for a library to play with signals behind the back of the
application, no matter ones views on the default behaviour of SIGPIPE under
POSIX. Even if the application doesn't care about the xenstored socket, it my
care about others.
This logic has existed since xenstore/xenstored was
Right now there are two completely different struct xs_handle definitions,
depend on #ifdef USE_PTHREAD. One is especially well hidden, and often
escapes updates.
Rework struct xs_handle using some interior ifdefary. It's slightly longer,
but much easier to follow. Importanly, this makes it muc
If the sum of iov element lengths overflows, the XENSTORE_PAYLOAD_MAX can
pass, after which we'll write 4G of data with a good-looking length field, and
the remainder of the payload will be interpreted as subsequent commands.
Check each iov element length for XENSTORE_PAYLOAD_MAX before accmulatin
On Thu, Jul 18, 2024 at 12:10:00PM +0200, Jan Beulich wrote:
> Therefore with SHADOW_PAGING=n this is better compiled out, to avoid
> leaving around unreachable/dead code.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
I was going to suggest moving this to shadow specific code, bu
On Thu Jul 18, 2024 at 12:23 PM BST, Jan Beulich wrote:
> On 09.07.2024 17:52, Alejandro Vallejo wrote:
> > Making the union non-anonymous causes a lot of headaches,
>
> Maybe better "would cause", as that's not what you're doing here?
Yes, sounds better.
>
> > because a lot of code
> > relies on
On 18/07/2024 1:52 pm, Juergen Gross wrote:
> The CPU POOLS sections in MAINTAINERS can be dropped, as the SCHEDULING
> section has the same maintainers and it is covering the CPU POOLS files
> as well.
>
> Signed-off-by: Juergen Gross
Acked-by: Andrew Cooper
On 2024-07-18 06:10, Jan Beulich wrote:
Therefore with SHADOW_PAGING=n this is better compiled out, to avoid
leaving around unreachable/dead code.
Signed-off-by: Jan Beulich
Reviewed-by: Jason Andryuk
flight 186857 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186857/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186833
test-amd64-amd64-libvirt-xsm 15 migrate-s
On Thu, Jul 18, 2024 at 9:03 AM Jan Beulich wrote:
>
> On 18.07.2024 14:54, Tamas K Lengyel wrote:
> > On Thu, Jul 18, 2024 at 7:17 AM Jan Beulich wrote:
> >> On 26.06.2024 00:47, Tamas K Lengyel wrote:
> >>> +cd xen
> >>
> >> This looks to suggest that the expectation is for the script to be inv
Thank you, Olivier, this will be a great trial for the Xen Project and we
are grateful for Vates' support.
*Some FAQs for the community:*
- Will there be a virtual element?
- For this specific event, we will not have a virtual element so that
the meetup can focus on in-person colla
On 18.07.2024 14:54, Tamas K Lengyel wrote:
> On Thu, Jul 18, 2024 at 7:17 AM Jan Beulich wrote:
>> On 26.06.2024 00:47, Tamas K Lengyel wrote:
>>> +cd xen
>>
>> This looks to suggest that the expectation is for the script to be invoked
>> from the root of a xen.git clone. Imo something like
>>
>>
On 18.07.2024 14:52, Juergen Gross wrote:
> The CPU POOLS sections in MAINTAINERS can be dropped, as the SCHEDULING
> section has the same maintainers and it is covering the CPU POOLS files
> as well.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
On Thu, Jul 18, 2024 at 7:17 AM Jan Beulich wrote:
>
> On 26.06.2024 00:47, Tamas K Lengyel wrote:
> > --- /dev/null
> > +++ b/scripts/oss-fuzz/build.sh
> > @@ -0,0 +1,23 @@
> > +#!/bin/bash -eu
> > +# SPDX-License-Identifier: Apache-2.0
>
> Hmm. Aiui this line is supposed to make unnecessary ...
The CPU POOLS sections in MAINTAINERS can be dropped, as the SCHEDULING
section has the same maintainers and it is covering the CPU POOLS files
as well.
Signed-off-by: Juergen Gross
---
MAINTAINERS | 6 --
1 file changed, 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2b0c89452
On Thu, Jul 18, 2024 at 7:03 AM Jan Beulich wrote:
>
> On 26.06.2024 00:47, Tamas K Lengyel wrote:
> > This target enables integration into oss-fuzz. Changing invalid input return
> > to -1 as values other then 0/-1 are reserved by libfuzzer.
>
> And existing behavior (for afl) is unaffected becau
On Thu, Jul 18, 2024 at 12:30:10PM +0200, Jan Beulich wrote:
> Let the subtree fall under general x86 maintainership instead, then also
> properly reflecting Roger's role there.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
On 15.07.2024 20:32, Jason Andryuk wrote:
> On 2024-07-10 04:30, Sergiy Kibrik wrote:
>> Build AMD Architectural P-state driver when CONFIG_AMD is on, and
>> Intel Hardware P-States driver together with ACPI Processor P-States driver
>> when CONFIG_INTEL is on respectively, allowing for a platform-
On 09.07.2024 17:52, Alejandro Vallejo wrote:
> It's doing too many things at once and there's no clear way of defining what
> it's meant to do. This patch splits the function in two.
>
> 1. A reset function, parameterized by the FCW value. FCW_RESET means to
> reset
> the state to power-o
On 09.07.2024 17:52, Alejandro Vallejo wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1343,7 +1343,8 @@ void arch_get_info_guest(struct vcpu *v,
> vcpu_guest_context_u c)
> #define c(fld) (c.nat->fld)
> #endif
>
> -memcpy(&c.nat->fpu_ctxt, v->arch.fpu_ctxt, sizeof
flight 186854 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186854/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl 8 xen-boot fail in 186844 pass in 186854
test-armhf-armhf-libvirt 8
On 09.07.2024 17:52, Alejandro Vallejo wrote:
> Making the union non-anonymous causes a lot of headaches,
Maybe better "would cause", as that's not what you're doing here?
> because a lot of code
> relies on it being so, but it's possible to make a typedef of the anonymous
> union so all callsite
On 09.07.2024 17:52, Alejandro Vallejo wrote:
> Minor refactor to make xstate_all() use a helper rather than poking directly
> into the XSAVE header.
>
> No functional change
>
> Signed-off-by: Alejandro Vallejo
Acked-by: Jan Beulich
On 26.06.2024 00:47, Tamas K Lengyel wrote:
> --- /dev/null
> +++ b/scripts/oss-fuzz/build.sh
> @@ -0,0 +1,23 @@
> +#!/bin/bash -eu
> +# SPDX-License-Identifier: Apache-2.0
Hmm. Aiui this line is supposed to make unnecessary ...
> +# Copyright 2024 Google LLC
> +#
> +# Licensed under the Apache L
On 18/07/2024 11:30 am, Jan Beulich wrote:
> Let the subtree fall under general x86 maintainership instead, then also
> properly reflecting Roger's role there.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 26.06.2024 00:47, Tamas K Lengyel wrote:
> This target enables integration into oss-fuzz. Changing invalid input return
> to -1 as values other then 0/-1 are reserved by libfuzzer.
And existing behavior (for afl) is unaffected because there we (wrongly)
ignore the return value altogether.
> @@
Let the subtree fall under general x86 maintainership instead, then also
properly reflecting Roger's role there.
Signed-off-by: Jan Beulich
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -594,12 +594,6 @@ F: tools/misc/xen-cpuid.c
F: tools/tests/cpu-policy/
F: tools/tests/x86_emulator/
-X86
On 18/07/2024 11:11 am, Jan Beulich wrote:
> At least in pure address calculation use the intended basic construct
> instead of opend-coded left-shifting by PAGE_SHIFT. Leave alone page
> table entry calculations for now, as those aren't really calculating
> addresses.
>
> No functional change.
>
>
At least in pure address calculation use the intended basic construct
instead of opend-coded left-shifting by PAGE_SHIFT. Leave alone page
table entry calculations for now, as those aren't really calculating
addresses.
No functional change.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/guest/xe
On 18/07/2024 11:09 am, Jan Beulich wrote:
> This really is gfn_to_gaddr() in disguise; no need to have two variants
> of the same logic.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Therefore with SHADOW_PAGING=n this is better compiled out, to avoid
leaving around unreachable/dead code.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -271,6 +271,8 @@ int mtrr_get_type(const struct mtrr_stat
return overlap_mtrr_pos;
}
+#ifdef
This really is gfn_to_gaddr() in disguise; no need to have two variants
of the same logic.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/include/asm/guest_pt.h
+++ b/xen/arch/x86/include/asm/guest_pt.h
@@ -20,12 +20,6 @@
#error GUEST_PAGING_LEVELS not defined
#endif
-static inline paddr_t
-g
On 17.07.2024 18:14, Andrew Cooper wrote:
> l1_disallow_mask() yields L1_DISALLOW_MASK with PAGE_CACHE_ATTRS conditionally
> permitted. First, rewrite it as a plain function.
>
> Next, correct some dubious behaviours.
>
> The use of is_pv_domain() is tautological; l1_disallow_mask() is only used
On 17.07.2024 18:14, Andrew Cooper wrote:
> base_disallow_mask is calculated once in arch_init_memory() and never changes
> thereafter. Write-protect it at runtime.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 17.07.2024 18:14, Andrew Cooper wrote:
> Even in release builds, gdprintk() evalues its parameters for side effects,
> and l1_disallow_mask() is full of them.
>
> Calculate the disallow mask once and reuse the variable. This improves code
> generation in release builds:
>
> add/remove: 0/0
On 18.07.2024 01:02, Stefano Stabellini wrote:
> On Wed, 17 Jul 2024, Jan Beulich wrote:
>> On 17.07.2024 02:20, Stefano Stabellini wrote:
>>> On Tue, 16 Jul 2024, Jan Beulich wrote:
On 16.07.2024 02:43, Stefano Stabellini wrote:
> On Mon, 15 Jul 2024, Jan Beulich wrote:
>> On 13.07.20
flight 186850 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186850/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-build fail in 186838 REGR. vs. 185867
build-i386-pre
65 matches
Mail list logo
