On 28.09.22 07:30, Juergen Gross wrote:
On 28.09.22 01:16, Borislav Petkov wrote:
On Tue, Sep 27, 2022 at 02:21:17PM +0200, Juergen Gross wrote:
So replacing the bool with "(system_state != SYSTEM_RUNNING)" is fine
with you right now? We can later switch that to the "more elegant"
solution when
On 28.09.22 01:16, Borislav Petkov wrote:
On Tue, Sep 27, 2022 at 02:21:17PM +0200, Juergen Gross wrote:
So replacing the bool with "(system_state != SYSTEM_RUNNING)" is fine
with you right now? We can later switch that to the "more elegant"
solution when it shows up.
Ok, I think I have someth
> From: Marczykowski, Marek
> Sent: Tuesday, September 27, 2022 7:54 AM
>
> On Fri, Sep 23, 2022 at 07:21:04AM +, Tian, Kevin wrote:
> > > From: Marek Marczykowski-Górecki
> > > Sent: Saturday, September 17, 2022 10:51 AM
> > >
> > > Re-use rmrr= parameter handling code to handle common devic
flight 173342 xen-unstable-smoke real [real]
flight 173344 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173342/
http://logs.test-lab.xenproject.org/osstest/logs/173344/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
flight 173341 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173341/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f4d539007c706ad9a563f368720edf0920da925d
baseline version:
ovmf b3dd9cb836e2aed68198a
flight 173337 qemu-mainline real [real]
flight 173340 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173337/
http://logs.test-lab.xenproject.org/osstest/logs/173340/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
On Tue, 27 Sep 2022, Jan Beulich wrote:
> On 27.09.2022 17:47, Andrew Cooper wrote:
> > This breaks all Clang builds, as demostrated by Gitlab CI.
> >
> > Contrary to the description in ecd6b9759919, -no-pie is not even an option
> > passed to the linker. GCC's actual behaviour is to inhibit the
On Tue, 27 Sep 2022, Andrew Cooper wrote:
> On 27/09/2022 23:47, Stefano Stabellini wrote:
> > On Mon, 26 Sep 2022, Andrew Cooper wrote:
> >> buster-gcc-ibt is a dedicated test to run a not-yet-upstreamed compiler
> >> patch
> >> which is relevant to CONFIG_XEN_IBT in 4.17 and later.
> >>
> >> For
On Tue, 27 Sep 2022, Michal Orzel wrote:
> Perform the following cleanup:
> - rename the device tree from virt-gicv3 to virt-gicv2 as the GIC version
> used in this test is v2,
> - use fdtput to perform modifications on the dtb,
> - use DEBIAN_FRONTEND=noninteractive to prevent interactive prompt
On Tue, 27 Sep 2022, Michal Orzel wrote:
> The correct variable name is DEBIAN_FRONTEND and not DEBIAN_FRONTENT.
>
> Signed-off-by: Michal Orzel
Reviewed-by: Stefano Stabellini
and committed
> ---
> CC: Henry Wang
>
> Rationale for taking this patch for 4.17:
> Setting DEBIAN_FRONTEND to no
On 27/09/2022 23:47, Stefano Stabellini wrote:
> On Mon, 26 Sep 2022, Andrew Cooper wrote:
>> buster-gcc-ibt is a dedicated test to run a not-yet-upstreamed compiler patch
>> which is relevant to CONFIG_XEN_IBT in 4.17 and later.
>>
>> Force it on, rather than having 50% of the jobs not testing wha
On Tue, Sep 27, 2022 at 02:21:17PM +0200, Juergen Gross wrote:
> So replacing the bool with "(system_state != SYSTEM_RUNNING)" is fine
> with you right now? We can later switch that to the "more elegant"
> solution when it shows up.
Ok, I think I have something. And it was staring me straight in t
On Mon, 26 Sep 2022, Andrew Cooper wrote:
> buster-gcc-ibt is a dedicated test to run a not-yet-upstreamed compiler patch
> which is relevant to CONFIG_XEN_IBT in 4.17 and later.
>
> Force it on, rather than having 50% of the jobs not testing what they're
> supposed to be testing.
>
> Fixes: 5d59
flight 173336 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173336/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 173326
test-armhf-armhf-libvirt 16 saver
On 9/27/22 21:23, Paolo Abeni wrote:
On Tue, 2022-09-27 at 21:17 +0100, Pavel Begunkov wrote:
On 9/27/22 20:59, Paolo Abeni wrote:
On Tue, 2022-09-27 at 19:48 +0100, Pavel Begunkov wrote:
On 9/27/22 18:56, Paolo Abeni wrote:
On Tue, 2022-09-27 at 18:16 +0100, Pavel Begunkov wrote:
On 9/27/22
On Tue, 2022-09-27 at 21:17 +0100, Pavel Begunkov wrote:
> On 9/27/22 20:59, Paolo Abeni wrote:
> > On Tue, 2022-09-27 at 19:48 +0100, Pavel Begunkov wrote:
> > > On 9/27/22 18:56, Paolo Abeni wrote:
> > > > On Tue, 2022-09-27 at 18:16 +0100, Pavel Begunkov wrote:
> > > > > On 9/27/22 15:28, Pavel
On 9/27/22 20:59, Paolo Abeni wrote:
On Tue, 2022-09-27 at 19:48 +0100, Pavel Begunkov wrote:
On 9/27/22 18:56, Paolo Abeni wrote:
On Tue, 2022-09-27 at 18:16 +0100, Pavel Begunkov wrote:
On 9/27/22 15:28, Pavel Begunkov wrote:
Hello Paolo,
On 9/27/22 14:49, Paolo Abeni wrote:
Hello,
On Fr
On Tue, 2022-09-27 at 19:48 +0100, Pavel Begunkov wrote:
> On 9/27/22 18:56, Paolo Abeni wrote:
> > On Tue, 2022-09-27 at 18:16 +0100, Pavel Begunkov wrote:
> > > On 9/27/22 15:28, Pavel Begunkov wrote:
> > > > Hello Paolo,
> > > >
> > > > On 9/27/22 14:49, Paolo Abeni wrote:
> > > > > Hello,
> >
On 9/27/22 18:56, Paolo Abeni wrote:
On Tue, 2022-09-27 at 18:16 +0100, Pavel Begunkov wrote:
On 9/27/22 15:28, Pavel Begunkov wrote:
Hello Paolo,
On 9/27/22 14:49, Paolo Abeni wrote:
Hello,
On Fri, 2022-09-23 at 17:39 +0100, Pavel Begunkov wrote:
struct ubuf_info is large but not all field
Hi Elliott,
Thanks!
As per the link you shared, VNC & SDL are two ways to get GUI display up
for guests. I am going through VNC & tried SDL, added below line in
guest1.cfg file.
*vfb = [ 'sdl=1' ]*
when creating guest machine by running command "*xl create -c guest1.cfg" *then
its throwing errors
flight 173327 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173327/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 173322
test-armhf-armhf-libvirt 16 save
On Tue, 2022-09-27 at 18:16 +0100, Pavel Begunkov wrote:
> On 9/27/22 15:28, Pavel Begunkov wrote:
> > Hello Paolo,
> >
> > On 9/27/22 14:49, Paolo Abeni wrote:
> > > Hello,
> > >
> > > On Fri, 2022-09-23 at 17:39 +0100, Pavel Begunkov wrote:
> > > > struct ubuf_info is large but not all fields a
On Wed, Jul 13, 2022 at 06:03:11PM +0300, dmitry.semen...@gmail.com wrote:
> From: Oleksandr Andrushchenko
>
> Add pcid daemon (based on vchan-node2) implements pcid protocol. Protocol is
> OS independed and should work on ane supported OS.
>
> Add essential functionality to handle pcid protocol
On 9/27/22 15:28, Pavel Begunkov wrote:
Hello Paolo,
On 9/27/22 14:49, Paolo Abeni wrote:
Hello,
On Fri, 2022-09-23 at 17:39 +0100, Pavel Begunkov wrote:
struct ubuf_info is large but not all fields are needed for all
cases. We have limited space in io_uring for it and large ubuf_info
prevent
flight 17 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/17/
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
SRAT may describe individual nodes using multiple ranges. When they're
adjacent (with or without a gap in between), only the start of the first
such range actually needs accounting for. Furthermore the very first
range doesn't need considering of its start address at all, as it's fine
to associate
This accidentally broke compatibility with OCaml 4.02.3,
only realized when I went back to my Dune based build system which can
automatically compile with multiple compiler versions.
See below for a patch for that. I've included this patch in the correct place
(before the patch that breaks it)
On 27.09.2022 17:53, Roger Pau Monné wrote:
> On Tue, Sep 27, 2022 at 04:15:19PM +0200, Jan Beulich wrote:
>> SRAT may describe even a single node system (including such with
>> multiple nodes, but only one having any memory) using multiple ranges.
>> Hence simply counting the number of ranges (not
On Tue, Sep 27, 2022 at 04:15:19PM +0200, Jan Beulich wrote:
> SRAT may describe even a single node system (including such with
> multiple nodes, but only one having any memory) using multiple ranges.
> Hence simply counting the number of ranges (note that function
> parameters are mis-named) is no
On 27.09.2022 17:47, Andrew Cooper wrote:
> This breaks all Clang builds, as demostrated by Gitlab CI.
>
> Contrary to the description in ecd6b9759919, -no-pie is not even an option
> passed to the linker. GCC's actual behaviour is to inhibit the passing of
> -pie to the linker, as well as select
On 20.09.2022 11:12, Wei Chen wrote:
> +static bool __init nodes_cover_memory(void)
> +{
> +unsigned int i;
> +
> +for ( i = 0; ; i++ )
> +{
> +int err;
> +bool found;
> +unsigned int j;
> +paddr_t start, end;
> +
> +/* Try to loop memory map from
This breaks all Clang builds, as demostrated by Gitlab CI.
Contrary to the description in ecd6b9759919, -no-pie is not even an option
passed to the linker. GCC's actual behaviour is to inhibit the passing of
-pie to the linker, as well as selecting different cr0 artefacts to be linked.
EMBEDDED_
memory_type_changed() is currently only implemented for Intel EPT, and
results in the invalidation of EMT attributes on all the entries in
the EPT page tables. Such invalidation causes EPT_MISCONFIG vmexits
when the guest tries to access any gfns for the first time, which
results in the recalculat
On 27/09/2022 15:38, Jan Beulich wrote:
> On 27.09.2022 16:32, Roger Pau Monné wrote:
>> On Mon, Sep 26, 2022 at 11:58:34AM +0200, Jan Beulich wrote:
>>> I don't expect it was intended to default PVH Dom0 to "no assist" mode.
>>> Introduce command line (sub-)options allowing to suppress enabling of
On 27.09.2022 16:31, Carlo Nonato wrote:
> On Mon, Sep 19, 2022 at 10:38 AM Jan Beulich wrote:
>> On 16.09.2022 18:07, Carlo Nonato wrote:
>>> On Thu, Sep 15, 2022 at 3:25 PM Jan Beulich wrote:
On 26.08.2022 14:51, Carlo Nonato wrote:
> @@ -218,6 +221,28 @@ void *__vmap(const mfn_t *mfn,
On 27.09.2022 17:07, Roger Pau Monné wrote:
> On Tue, Sep 27, 2022 at 04:32:27PM +0200, Jan Beulich wrote:
>> On 27.09.2022 16:14, Roger Pau Monné wrote:
>>> On Fri, Sep 09, 2022 at 09:22:52AM +0200, Jan Beulich wrote:
While I was suspicious of the compiler issuing a diagnostic about an
u
On Tue, Sep 27, 2022 at 04:32:27PM +0200, Jan Beulich wrote:
> On 27.09.2022 16:14, Roger Pau Monné wrote:
> > On Fri, Sep 09, 2022 at 09:22:52AM +0200, Jan Beulich wrote:
> >> While I was suspicious of the compiler issuing a diagnostic about an
> >> unused linking-only option when not doing any li
Hi Dmitry,
On Wed, Jul 13, 2022 at 06:03:09PM +0300, dmitry.semen...@gmail.com wrote:
> diff --git a/tools/libs/vchan/init.c b/tools/libs/vchan/init.c
> index 9195bd3b98..38658f30af 100644
> --- a/tools/libs/vchan/init.c
> +++ b/tools/libs/vchan/init.c
> @@ -259,6 +259,12 @@ static int init_xs_srv
On 27.09.2022 16:44, Alex Bennée wrote:
> Jan Beulich writes:
>> @@ -127,7 +128,7 @@ static int __init extract_lsb_from_nodes
>> if ( spdx >= epdx )
>> continue;
>> bitfield |= spdx;
>> -nodes_used++;
>> +nodes_used += i == 0 || !nodeids || nodeids[i
Jan Beulich writes:
> SRAT may describe even a single node system (including such with
> multiple nodes, but only one having any memory) using multiple ranges.
> Hence simply counting the number of ranges (note that function
> parameters are mis-named) is not an indication of the number of node
On 27.09.2022 16:32, Roger Pau Monné wrote:
> On Mon, Sep 26, 2022 at 11:58:34AM +0200, Jan Beulich wrote:
>> I don't expect it was intended to default PVH Dom0 to "no assist" mode.
>> Introduce command line (sub-)options allowing to suppress enabling of
>> the assists, paralleling the guest config
On Thu, Sep 22, 2022 at 08:29:52AM +0200, Jan Beulich wrote:
> On 01.08.2022 10:57, Juergen Gross wrote:
> > On 13.07.22 17:03, dmitry.semen...@gmail.com wrote:
> >> From: Oleksandr Andrushchenko
> >>
> >> vchan server creates XenStore entries to advertise its event channel and
> >> ring, but thos
On 27.09.2022 16:29, Andrew Cooper wrote:
> On 27/09/2022 15:14, Roger Pau Monne wrote:
>> On Fri, Sep 09, 2022 at 09:22:52AM +0200, Jan Beulich wrote:
>>> While I was suspicious of the compiler issuing a diagnostic about an
>>> unused linking-only option when not doing any linking, I did check thi
On Mon, Sep 26, 2022 at 11:58:34AM +0200, Jan Beulich wrote:
> I don't expect it was intended to default PVH Dom0 to "no assist" mode.
> Introduce command line (sub-)options allowing to suppress enabling of
> the assists, paralleling the guest config settings for DomU, but restore
> the defaulting
On 27.09.2022 16:14, Roger Pau Monné wrote:
> On Fri, Sep 09, 2022 at 09:22:52AM +0200, Jan Beulich wrote:
>> While I was suspicious of the compiler issuing a diagnostic about an
>> unused linking-only option when not doing any linking, I did check this
>> with a couple of gcc versions only, but no
Hi Jan,
On Mon, Sep 19, 2022 at 10:38 AM Jan Beulich wrote:
>
> On 16.09.2022 18:07, Carlo Nonato wrote:
> > On Thu, Sep 15, 2022 at 3:25 PM Jan Beulich wrote:
> >> On 26.08.2022 14:51, Carlo Nonato wrote:
> >>> @@ -218,6 +221,28 @@ void *__vmap(const mfn_t *mfn, unsigned int
> >>> granularity,
Hi Wei,
On Mon, Sep 26, 2022 at 8:39 AM Wei Chen wrote:
> On 2022/8/26 20:51, Carlo Nonato wrote:
> > +int domain_coloring_init(struct domain *d,
> > + const struct xen_arch_domainconfig *config)
> > +{
> > +if ( is_domain_direct_mapped(d) )
> > +{
> > +pri
Hi Jan, Wei
On Mon, Sep 26, 2022 at 9:42 AM Jan Beulich wrote:
>
> On 26.09.2022 08:20, Wei Chen wrote:
> > On 2022/8/26 20:51, Carlo Nonato wrote:
> >> --- a/xen/arch/arm/Kconfig
> >> +++ b/xen/arch/arm/Kconfig
> >> @@ -131,6 +131,22 @@ config ARM64_BTI
> >>Branch Target Identification s
Hello Paolo,
On 9/27/22 14:49, Paolo Abeni wrote:
Hello,
On Fri, 2022-09-23 at 17:39 +0100, Pavel Begunkov wrote:
struct ubuf_info is large but not all fields are needed for all
cases. We have limited space in io_uring for it and large ubuf_info
prevents some struct embedding, even though we u
On 27/09/2022 15:14, Roger Pau Monne wrote:
> On Fri, Sep 09, 2022 at 09:22:52AM +0200, Jan Beulich wrote:
>> While I was suspicious of the compiler issuing a diagnostic about an
>> unused linking-only option when not doing any linking, I did check this
>> with a couple of gcc versions only, but no
SRAT may describe even a single node system (including such with
multiple nodes, but only one having any memory) using multiple ranges.
Hence simply counting the number of ranges (note that function
parameters are mis-named) is not an indication of the number of nodes in
use. Since we only care abo
On Fri, Sep 09, 2022 at 09:22:52AM +0200, Jan Beulich wrote:
> While I was suspicious of the compiler issuing a diagnostic about an
> unused linking-only option when not doing any linking, I did check this
> with a couple of gcc versions only, but not with Clang. (Oddly enough at
> least older Clan
extract_lsb_from_nodes() accumulates "memtop" from all PDXes one past
the covered ranges. Hence the maximum address which can validly by used
to index the node map is one below this value, and we may currently set
up a node map with an unused (and never initialized) trailing entry. In
boundary case
extract_lsb_from_nodes() accumulates "memtop" from all PDXes one past
the covered ranges. Hence the maximum address which can validly by used
to index the node map is one below this value, and we may currently set
up a node map with an unused (and never initialized) trailing entry. In
boundary case
Hello,
On Fri, 2022-09-23 at 17:39 +0100, Pavel Begunkov wrote:
> struct ubuf_info is large but not all fields are needed for all
> cases. We have limited space in io_uring for it and large ubuf_info
> prevents some struct embedding, even though we use only a subset
> of the fields. It's also not
flight 173326 linux-linus real [real]
flight 173329 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173326/
http://logs.test-lab.xenproject.org/osstest/logs/173329/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On Tue, Sep 6, 2022 at 8:45 AM Jason Andryuk wrote:
>
> On Mon, Sep 5, 2022 at 9:50 AM Marek Marczykowski-Górecki
> wrote:
> >
> > This enables stubdom reliably detect when it needs to reconnect QMP
> > socket. It is critical, as otherwise QEMU will not send its handshake,
> > and so libxl will t
On 27.09.22 14:13, Borislav Petkov wrote:
On Tue, Sep 27, 2022 at 01:25:47PM +0200, Juergen Gross wrote:
You mean by replacing it with "(system_state != SYSTEM_RUNNING)" ?
Right, or maybe even something more elegant. I've been meaning to ask
tglx about it as I needed it for the microcode loade
On Tue, Sep 27, 2022 at 01:25:47PM +0200, Juergen Gross wrote:
> You mean by replacing it with "(system_state != SYSTEM_RUNNING)" ?
Right, or maybe even something more elegant. I've been meaning to ask
tglx about it as I needed it for the microcode loader too.
--
Regards/Gruss,
Boris.
https
On 27.09.22 13:19, Borislav Petkov wrote:
On Tue, Sep 27, 2022 at 12:14:42PM +0200, Juergen Gross wrote:
Yes: cpu hotplug.
You might need to elaborate here.
Because I see mtrr_ap_init() on the AP hotplug path:
native_cpu_up->
do_boot_cpu->
start_secondary->
smp_callin->
smp_store_cpu_info->
On Tue, Sep 27, 2022 at 12:14:42PM +0200, Juergen Gross wrote:
> Yes: cpu hotplug.
You might need to elaborate here.
Because I see mtrr_ap_init() on the AP hotplug path:
native_cpu_up->
do_boot_cpu->
start_secondary->
smp_callin->
smp_store_cpu_info->
identify_secondary_cpu->
mtrr_ap_init
Which
Signed-off-by: Edwin Török
---
tools/ocaml/Makefile.rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/ocaml/Makefile.rules b/tools/ocaml/Makefile.rules
index 0d3c6ac839..e0b9de34e4 100644
--- a/tools/ocaml/Makefile.rules
+++ b/tools/ocaml/Makefile.rules
@@ -44,7 +44,
Signed-off-by: Edwin Török
---
tools/ocaml/Makefile.rules | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/ocaml/Makefile.rules b/tools/ocaml/Makefile.rules
index e0b9de34e4..39ac260a4d 100644
--- a/tools/ocaml/Makefile.rules
+++ b/tools/ocaml/Makefile.rules
@@ -44,10
Follow the manual to avoid naked pointers:
https://v2.ocaml.org/manual/intfc.html#ss:c-outside-head
No functional change, except on OCaml 5.0 where it is a bugfix.
Signed-off-by: Edwin Török
---
tools/ocaml/libs/xc/xenctrl_stubs.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-
Add a finalizer on the event channel value, so that it calls
`xenevtchn_close` when the value would be GCed.
In practice oxenstored seems to be the only user of this,
and it creates a single global event channel only,
but freeing this could still be useful when run with OCAMLRUNPARAM=c
The code w
Changes to previous series:
* removed Dune patches from this series for now (that requires more work to
work with osstest on Debian oldstable that won't be ready in time for 4.17)
* also updated xenctrl to work with no naked pointers mode (the only mode in
OCaml 5.0)
* changed alloc_custom to use
This is not strictly necessary since it is essentially a no-op
currently: a cast to void* and value*, even in OCaml 5.0.
However it does make it clearer that what we have here is not a regular
OCaml value, but one allocated with Abstract_tag or Custom_tag,
and follows the example from the manual m
On 27.09.22 12:10, Borislav Petkov wrote:
On Tue, Sep 27, 2022 at 10:57:37AM +0200, Juergen Gross wrote:
TBH I don't see the point of having an accessor which is just setting a
variable to "true". But if you like it better, I can keep it.
Accessors are always better, no matter how silly. :)
On Tue, Sep 27, 2022 at 10:57:37AM +0200, Juergen Gross wrote:
> TBH I don't see the point of having an accessor which is just setting a
> variable to "true". But if you like it better, I can keep it.
Accessors are always better, no matter how silly. :)
But, in trying to grok your next patch - yo
Hi Michal,
> -Original Message-
> From: Michal Orzel
> Subject: [for-4.17,PATCH v3 01/10] automation: qemu-smoke-arm{32/64}.sh:
> Fix typo in DEBIAN_FRONTENT
>
> The correct variable name is DEBIAN_FRONTEND and not DEBIAN_FRONTENT.
>
> Signed-off-by: Michal Orzel
> ---
> CC: Henry Wang
> On 27 Sep 2022, at 10:47, Michal Orzel wrote:
>
> The correct variable name is DEBIAN_FRONTEND and not DEBIAN_FRONTENT.
>
> Signed-off-by: Michal Orzel
> ---
> CC: Henry Wang
>
> Rationale for taking this patch for 4.17:
> Setting DEBIAN_FRONTEND to noninteractive menas that we need zero
> On 27 Sep 2022, at 10:47, Michal Orzel wrote:
>
> Perform the following cleanup:
> - rename the device tree from virt-gicv3 to virt-gicv2 as the GIC version
> used in this test is v2,
> - use fdtput to perform modifications on the dtb,
> - use DEBIAN_FRONTEND=noninteractive to prevent inter
flight 173325 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173325/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 173303
test-armhf-armhf-libvirt-raw 15 saveresto
After qemu arm64 test scripts had been renamed to reflect their
usage, do the same for the qemu arm32 test script. Currently it only
boots dom0, so we can assume that this script will be used to perform
dom0 based testing. In the future we will be able to create corresponding
script qemu-smoke-dom0
Testing arm64 is done using the qemu-alpine-arm64.sh and
qemu-smoke-arm64.sh scripts. These scripts are executed with exactly
the same artifacts (container, rootfs, kernel, qemu) and the only
difference is that the former is used to perform dom0 based testing
and the latter - dom0less based testing
Take an example from arm64 qemu test scripts and use ImageBuilder
to generate u-boot script automatically. Calculating the addresses
manually is quite error prone and also we will be able to benefit
from using ImageBuilder when adding domUs to this test in the future.
Install and use u-boot from t
qemu-alpine-arm64.sh script is used to perform dom0 based testing.
Rename this script to qemu-smoke-dom0-arm64.sh to reflect its usage.
Also rename the corresponding test jobs.
Signed-off-by: Michal Orzel
Acked-by: Stefano Stabellini
---
Changes in v3:
- none
Changes in v2:
- none
---
automatio
In the follow-up patch we will add new jobs using debug Xen builds.
Because the debug builds take more space and we might end up in
a situation when there is not enough free space (especially during
a static memory test that reserves some region in the middle), increase
RAM size for QEMU from 1GB t
Perform the following cleanup:
- rename the device tree from virt-gicv3 to virt-gicv2 as the GIC version
used in this test is v2,
- use fdtput to perform modifications on the dtb,
- use DEBIAN_FRONTEND=noninteractive to prevent interactive prompt being
stuck waiting for answer other than "yes",
At the moment, all the tests are executed on non-debug Xen builds.
To improve the coverage (e.g. we might catch some asserts), add new
test jobs using debug Xen builds.
Signed-off-by: Michal Orzel
Reviewed-by: Stefano Stabellini
Reviewed-by: Luca Fancellu
---
Changes in v3:
- none
Changes in v2
This patch series performs necessary cleanup and improvements in our
GitLab CI automation for Arm. This is crucial so that in the future
we can focus on adding new tests instead of spending time to fix
issues, making the behavior consistent, removing ambiguity, etc.
With the increased interest in
For arm64 we perform builds using debian and alpine containers.
We are missing the randconfig build jobs for the latter, so add them.
This way for each container we have 4 fundamental build jobs:
- defconfig non-debug/debug
- randconfig non-debug/debug
Signed-off-by: Michal Orzel
Reviewed-by: Ste
The correct variable name is DEBIAN_FRONTEND and not DEBIAN_FRONTENT.
Signed-off-by: Michal Orzel
---
CC: Henry Wang
Rationale for taking this patch for 4.17:
Setting DEBIAN_FRONTEND to noninteractive menas that we need zero interaction
while installing/upgrading the system via apt-get. It acce
Script automation/scripts/containerize makes it easy to build Xen within
predefined containers from gitlab container registry. This script is
currently missing the helpers to select Arm containers, so populate the
necessary entries.
Signed-off-by: Michal Orzel
Acked-by: Stefano Stabellini
---
Ch
On 27.09.2022 10:19, Jan Beulich wrote:
> On 20.09.2022 11:12, Wei Chen wrote:
>> +static unsigned int __init extract_lsb_from_nodes(const struct node *nodes,
>> + nodeid_t numnodes)
>> +{
>> +unsigned int i, nodes_used = 0;
>> +unsigned long
On Mon, Sep 26, 2022 at 06:03:24PM +, Andrew Cooper wrote:
> On 22/09/2022 17:05, Roger Pau Monne wrote:
> > memory_type_changed() is currently only implemented for Intel EPT, and
> > results in the invalidation of EMT attributes on all the entries in
> > the EPT page tables. Such invalidation
On 26.09.22 23:11, Borislav Petkov wrote:
On Thu, Sep 08, 2022 at 10:49:12AM +0200, Juergen Gross wrote:
-void set_mtrr_aps_delayed_init(void)
-{
- if (!cache_generic)
- return;
-
- mtrr_aps_delayed_init = true;
-}
-
Except that you've removed the accessors and made t
Hi Rahul and all,
> -Original Message-
> From: Rahul Singh
> Subject: Re: [PATCH 0/2] xen/arm: static event channel
>
> Hi All,
> > On 26 Sep 2022, at 1:12 pm, Bertrand Marquis
> wrote:
> > Hi Rahul,
> >
> > Please give the necessary justification for inclusion in 4.17:
> > - severity o
Hi All,
> On 26 Sep 2022, at 1:12 pm, Bertrand Marquis wrote:
>
> Hi Rahul,
>
> Please give the necessary justification for inclusion in 4.17:
> - severity of the bug fixed
The severity of the bug is high as without this fixed system with ACPI support
will fail to boot.
> - probability and i
On Tue, Sep 27, 2022 at 08:35:20AM +0200, Jan Beulich wrote:
> On 26.09.2022 17:58, Roger Pau Monné wrote:
> > On Mon, Sep 26, 2022 at 05:36:41PM +0200, Jan Beulich wrote:
> >> On 26.09.2022 17:25, Roger Pau Monné wrote:
> >>> Correction: the Arm memory_type_changed() needs to stay, as
> >>> iomem_
On 20.09.2022 11:12, Wei Chen wrote:
> There are some codes in x86/numa.c can be shared by common
> architectures to implememnt NUMA support. Just like some
> variables and functions to check and store NUMA memory map.
> And some variables and functions to do NUMA initialization.
>
> In this patch
flight 173322 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173322/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-qemut-rhel6hvm-amd 7 xen-install fail in 173316 pass in 173322
test-armhf-armhf-xl-rtds 18 gues
Hi Michal,
> -Original Message-
> Subject: [for-4.17 v2] xen/arm: domain_build: Always print the static shared
> memory region
>
> At the moment, the information about allocating static shared memory
> region is only printed during the debug build. This information can also
> be helpful f
On 20.09.2022 11:12, Wei Chen wrote:
> --- a/xen/arch/x86/numa.c
> +++ b/xen/arch/x86/numa.c
> @@ -50,9 +50,28 @@ nodemask_t __read_mostly node_online_map = { { [0] = 1UL }
> };
> bool numa_off;
> s8 acpi_numa = 0;
>
> -int srat_disabled(void)
> +int __init arch_numa_setup(const char *opt)
>
On 26.09.22 17:52, Jan Beulich wrote:
On 26.09.2022 10:33, Juergen Gross wrote:
On 26.09.22 09:53, Jan Beulich wrote:
On 23.09.2022 10:20, Juergen Gross wrote:
My favorite solution would be some kind of buffer address qualifier for each
buffer (e.g. virtual, physical, SG-list, maybe nested SG-
95 matches
Mail list logo
