On 25.06.2024 08:46, Federico Serafini wrote:
> Update ECLAIR configuration to deviate more cases where an
> unintentional fallthrough cannot happen.
>
> Tag Rule 16.3 as clean for arm.
>
> Signed-off-by: Federico Serafini
> Acked-by: Stefano Stabellini
To add to my reply on the other series:
On 25.06.24 08:34, Jan Beulich wrote:
On 25.06.2024 02:15, victorm.l...@amd.com wrote:
From: Victor Lira
Rule 17.7: "The value returned by a function having non-void return type
shall be used"
This patch fixes this by adding a check to the return value.
No functional changes.
Signed-off-by:
On 24/06/24 17:32, Jan Beulich wrote:
On 24.06.2024 11:04, Federico Serafini wrote:
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -339,7 +339,7 @@ static int hvmemul_do_io(
}
case X86EMUL_UNIMPLEMENTED:
ASSERT_UNREACHABLE();
-/* Fall-through *
The odd DEFINE_XEN_GUEST_HANDLE(), inconsistent with all other similar
constructs, should have caught my attention. Turns out it was needed for
the build to succeed merely because the corresponding #ifndef had a
typo. That typo in turn broke compat mode guests, by having query-size
requests of thei
On 24/06/24 17:39, Jan Beulich wrote:
On 24.06.2024 11:04, Federico Serafini wrote:
Add defensive return statement at the end of an unreachable
default case. Other than improve safety,
It is particularly with this in mind that ...
this meets the requirements
to deviate a violation of MISRA C
On 2024/6/24 16:13, Jan Beulich wrote:
> On 21.06.2024 10:15, Chen, Jiqian wrote:
>> On 2024/6/20 18:37, Jan Beulich wrote:
>>> On 20.06.2024 12:23, Chen, Jiqian wrote:
On 2024/6/20 15:43, Jan Beulich wrote:
> On 20.06.2024 09:03, Chen, Jiqian wrote:
>> On 2024/6/18 17:13, Jan Beulich
On 25.06.2024 09:30, Jan Beulich wrote:
> The odd DEFINE_XEN_GUEST_HANDLE(), inconsistent with all other similar
> constructs, should have caught my attention. Turns out it was needed for
> the build to succeed merely because the corresponding #ifndef had a
> typo. That typo in turn broke compat mo
On 2024/6/24 16:17, Jan Beulich wrote:
> On 21.06.2024 10:20, Chen, Jiqian wrote:
>> On 2024/6/20 18:42, Jan Beulich wrote:
>>> On 20.06.2024 11:40, Chen, Jiqian wrote:
On 2024/6/18 17:23, Jan Beulich wrote:
> On 18.06.2024 10:23, Chen, Jiqian wrote:
>> On 2024/6/17 23:32, Jan Beulich
On 2024/6/24 20:33, Anthony PERARD wrote:
> On Fri, Jun 21, 2024 at 08:20:55AM +, Chen, Jiqian wrote:
>> On 2024/6/20 18:42, Jan Beulich wrote:
>>> On 20.06.2024 11:40, Chen, Jiqian wrote:
On 2024/6/18 17:23, Jan Beulich wrote:
> On 18.06.2024 10:23, Chen, Jiqian wrote:
>> On 2024/
On 25.06.2024 09:21, Federico Serafini wrote:
> On 24/06/24 17:32, Jan Beulich wrote:
>> On 24.06.2024 11:04, Federico Serafini wrote:
>>> @@ -2674,6 +2674,7 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt
>>> *hvmemul_ctxt,
>>>
>>> default:
>>> ASSERT_UNREACHABLE();
>>>
On 25.06.2024 09:44, Chen, Jiqian wrote:
> On 2024/6/24 16:17, Jan Beulich wrote:
>> On 21.06.2024 10:20, Chen, Jiqian wrote:
>>> On 2024/6/20 18:42, Jan Beulich wrote:
Alternatively we could maybe enable XEN_DOMCTL_getdomaininfo to permit
DOMID_SELF.
>>> It didn't permit DOMID_SELF since
On 24/06/24 17:43, Jan Beulich wrote:
On 24.06.2024 11:04, Federico Serafini wrote:
Add missing break statement to address a violation of MISRA C Rule 16.3
("An unconditional `break' statement shall terminate every
switch-clause").
No functional change.
Signed-off-by: Federico Serafini
Acke
Pull in the gcc14 build fix there.
Signed-off-by: Jan Beulich
---
Probably nice to reference a gcc14-clean MiniOS tree from what is going
to be 4.19.
--- a/Config.mk
+++ b/Config.mk
@@ -224,7 +224,7 @@ QEMU_UPSTREAM_URL ?= https://xenbits.xen
QEMU_UPSTREAM_REVISION ?= master
MINIOS_UPSTREAM_
On 25.06.24 09:57, Jan Beulich wrote:
Pull in the gcc14 build fix there.
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
Juergen
On Mon, 2024-06-24 at 14:20 +0100, Andrew Cooper wrote:
> On 24/06/2024 1:26 pm, Jan Beulich wrote:
> > When re-working them to avoid UB on guest address calculations, I
> > failed
> > to add explicit type checks in exchange for the implicit ones that
> > until
> > then had happened in assignments
On Tue, 2024-06-25 at 09:57 +0200, Jan Beulich wrote:
> Pull in the gcc14 build fix there.
>
> Signed-off-by: Jan Beulich
> ---
> Probably nice to reference a gcc14-clean MiniOS tree from what is
> going
> to be 4.19.
I would like to ask what do you mean by gcc14-clean here?
~ Oleksii
>
> ---
On Tue, 2024-06-25 at 09:30 +0200, Jan Beulich wrote:
> The odd DEFINE_XEN_GUEST_HANDLE(), inconsistent with all other
> similar
> constructs, should have caught my attention. Turns out it was needed
> for
> the build to succeed merely because the corresponding #ifndef had a
> typo. That typo in tu
On Mon, 2024-06-24 at 17:22 -0700, Stefano Stabellini wrote:
> On Mon, 24 Jun 2024, Alessandro Zucchelli wrote:
> > Rule 21.2 reports identifiers reserved for the C and POSIX standard
> > libraries: or, and, not and xor are reserved identifiers because
> > they
> > constitute alternate spellings fo
On 25.06.2024 10:10, Oleksii wrote:
> On Tue, 2024-06-25 at 09:57 +0200, Jan Beulich wrote:
>> Pull in the gcc14 build fix there.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> Probably nice to reference a gcc14-clean MiniOS tree from what is
>> going
>> to be 4.19.
> I would like to ask what do you m
On Mon, 2024-06-24 at 17:26 -0700, Stefano Stabellini wrote:
> On Mon, 24 Jun 2024, Stefano Stabellini wrote:
> > On Mon, 24 Jun 2024, Federico Serafini wrote:
> > > Rule 13.6 states that "The operand of the `sizeof' operator shall
> > > not
> > > contain any expression which has potential side eff
In case cpu_schedule_up() is failing to allocate memory for struct
sched_resource, cpu_schedule_down() will be called with the
sched_resource pointer being NULL. This needs to be handled.
Reported-by: Jan Beulich
Fixes: 207589dbacd4 ("xen/sched: move per cpu scheduler private data into
struct sc
On Mon, 2024-06-24 at 22:40 +0100, Julien Grall wrote:
> Hi,
Hi Julien,
>
> On 24/06/2024 17:27, Stefano Stabellini wrote:
> > On Mon, 24 Jun 2024, Anthony PERARD wrote:
> > > Signed-off-by: Anthony PERARD
> >
> > Acked-by: Stefano Stabellini
>
> I guess this technically need an ack from the
On 25.06.2024 10:27, Juergen Gross wrote:
> In case cpu_schedule_up() is failing to allocate memory for struct
> sched_resource,
Or (just to mention it again) in case the function isn't called at all
because some earlier CPU_UP_PREPARE handler fails.
> cpu_schedule_down() will be called with the
On Tue, Jun 25, 2024 at 07:52:38AM +0200, Christoph Hellwig wrote:
> Ensure that info->sector_size and info->physical_sector_size are set
> before the call to blkif_set_queue_limits by doing away with the
> local variables and arguments that propagate them.
>
> Thanks to Marek Marczykowski-Górecki
On 25.06.24 10:33, Jan Beulich wrote:
On 25.06.2024 10:27, Juergen Gross wrote:
In case cpu_schedule_up() is failing to allocate memory for struct
sched_resource,
Or (just to mention it again) in case the function isn't called at all
because some earlier CPU_UP_PREPARE handler fails.
cpu_sch
Hi Oliver,
can you test the patch below? It restores the previous behavior if
the device did not have a volatile write cache. I think at least
for raid0 and raid1 without bitmap the new behavior actually is correct
and better, but it will need fixes for other modes. If the underlying
devices di
On 21.06.2024 21:14, Tamas K Lengyel wrote:
> --- /dev/null
> +++ b/scripts/oss-fuzz/build.sh
> @@ -0,0 +1,22 @@
> +#!/bin/bash -eu
> +# Copyright 2024 Google LLC
> +#
> +# Licensed under the Apache License, Version 2.0 (the "License");
> +# you may not use this file except in compliance with the L
On Tue, Jun 25, 2024 at 09:30:07AM +0200, Jan Beulich wrote:
> The odd DEFINE_XEN_GUEST_HANDLE(), inconsistent with all other similar
> constructs, should have caught my attention. Turns out it was needed for
> the build to succeed merely because the corresponding #ifndef had a
> typo. That typo in
On 25.06.2024 11:24, Roger Pau Monné wrote:
> On Tue, Jun 25, 2024 at 09:30:07AM +0200, Jan Beulich wrote:
>> The odd DEFINE_XEN_GUEST_HANDLE(), inconsistent with all other similar
>> constructs, should have caught my attention. Turns out it was needed for
>> the build to succeed merely because the
On 24/06/24 17:16, Jan Beulich wrote:
On 24.06.2024 11:04, Federico Serafini wrote:
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -713,6 +713,7 @@ static int cf_check core2_vpmu_do_rdmsr(unsigned int msr,
uint64_t *msr_content)
break;
default
flight 186479 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186479/
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
In the file common/kernel.c macro ARRAY_SIZE is called with argument
current->domain->handle.
Once expanded, this ARRAY_SIZE's argument is used in sizeof operations
and thus 'current', being a macro that expands to a function
call with potential side effects, generates a violation.
To address this
In the file common/softirq macro set_bit is called with argument
smp_processor_id.
Once expanded this set_bit's argument is used in sizeof operations
and thus 'smp_processor_id', being a macro that expands to a
function call with potential side effects, generates a violation.
To address this viola
This series aims to address several violations of Rule 13.6 which states the
following: The operand of the `sizeof' operator shall not contain any expression
which has potential side effects.
Alessandro Zucchelli (3):
common/kernel: address violation of MISRA C Rule 13.6
xen/event: address vio
In the file include/xen/event.h macro set_bit is called with argument
current->pause_flags.
Once expanded this set_bit's argument is used in sizeof operations
and thus 'current', being a macro that expands to a function
call with potential side effects, generates a violation.
To address this viola
On 25.06.24 10:33, Jan Beulich wrote:
On 25.06.2024 10:27, Juergen Gross wrote:
In case cpu_schedule_up() is failing to allocate memory for struct
sched_resource,
Or (just to mention it again) in case the function isn't called at all
because some earlier CPU_UP_PREPARE handler fails.
This re
flight 186474 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186474/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale broken
test-armhf-armhf-xl-arndale 5 host-insta
On 25/06/2024 8:30 am, Jan Beulich wrote:
> The odd DEFINE_XEN_GUEST_HANDLE(), inconsistent with all other similar
> constructs, should have caught my attention. Turns out it was needed for
> the build to succeed merely because the corresponding #ifndef had a
> typo. That typo in turn broke compat
On Tue, Jun 25, 2024 at 2:00 AM Jan Beulich wrote:
>
> On 24.06.2024 23:23, Tamas K Lengyel wrote:
> > On Mon, Jun 24, 2024 at 11:55 AM Jan Beulich wrote:
> >>
> >> On 21.06.2024 21:14, Tamas K Lengyel wrote:
> >>> @@ -58,6 +58,9 @@ afl-harness: afl-harness.o $(OBJS) cpuid.o wrappers.o
> >>> afl
On Tue, Jun 25, 2024 at 5:17 AM Jan Beulich wrote:
>
> On 21.06.2024 21:14, Tamas K Lengyel wrote:
> > --- /dev/null
> > +++ b/scripts/oss-fuzz/build.sh
> > @@ -0,0 +1,22 @@
> > +#!/bin/bash -eu
> > +# Copyright 2024 Google LLC
> > +#
> > +# Licensed under the Apache License, Version 2.0 (the "Lic
On Tue, Jun 25, 2024 at 5:17 AM Jan Beulich wrote:
>
> On 21.06.2024 21:14, Tamas K Lengyel wrote:
> > --- /dev/null
> > +++ b/scripts/oss-fuzz/build.sh
> > @@ -0,0 +1,22 @@
> > +#!/bin/bash -eu
> > +# Copyright 2024 Google LLC
> > +#
> > +# Licensed under the Apache License, Version 2.0 (the "Lic
On 25.06.2024 12:43, Andrew Cooper wrote:
> On 25/06/2024 8:30 am, Jan Beulich wrote:
>> The odd DEFINE_XEN_GUEST_HANDLE(), inconsistent with all other similar
>> constructs, should have caught my attention. Turns out it was needed for
>> the build to succeed merely because the corresponding #ifnde
On 25.06.2024 13:15, Tamas K Lengyel wrote:
> On Tue, Jun 25, 2024 at 5:17 AM Jan Beulich wrote:
>>
>> On 21.06.2024 21:14, Tamas K Lengyel wrote:
>>> --- /dev/null
>>> +++ b/scripts/oss-fuzz/build.sh
>>> @@ -0,0 +1,22 @@
>>> +#!/bin/bash -eu
>>> +# Copyright 2024 Google LLC
>>> +#
>>> +# Licensed
On 25.06.2024 13:12, Tamas K Lengyel wrote:
> On Tue, Jun 25, 2024 at 2:00 AM Jan Beulich wrote:
>>
>> On 24.06.2024 23:23, Tamas K Lengyel wrote:
>>> On Mon, Jun 24, 2024 at 11:55 AM Jan Beulich wrote:
On 21.06.2024 21:14, Tamas K Lengyel wrote:
> @@ -58,6 +58,9 @@ afl-harness: afl
On Tue, Jun 25, 2024 at 7:40 AM Jan Beulich wrote:
>
> On 25.06.2024 13:15, Tamas K Lengyel wrote:
> > On Tue, Jun 25, 2024 at 5:17 AM Jan Beulich wrote:
> >>
> >> On 21.06.2024 21:14, Tamas K Lengyel wrote:
> >>> --- /dev/null
> >>> +++ b/scripts/oss-fuzz/build.sh
> >>> @@ -0,0 +1,22 @@
> >>> +#
On Tue, Jun 25, 2024 at 7:52 AM Jan Beulich wrote:
>
> On 25.06.2024 13:12, Tamas K Lengyel wrote:
> > On Tue, Jun 25, 2024 at 2:00 AM Jan Beulich wrote:
> >>
> >> On 24.06.2024 23:23, Tamas K Lengyel wrote:
> >>> On Mon, Jun 24, 2024 at 11:55 AM Jan Beulich wrote:
>
> On 21.06.2024 21
On 25.06.2024 14:40, Tamas K Lengyel wrote:
> On Tue, Jun 25, 2024 at 7:52 AM Jan Beulich wrote:
>>
>> On 25.06.2024 13:12, Tamas K Lengyel wrote:
>>> On Tue, Jun 25, 2024 at 2:00 AM Jan Beulich wrote:
On 24.06.2024 23:23, Tamas K Lengyel wrote:
> On Mon, Jun 24, 2024 at 11:55 AM Ja
On 25.06.2024 14:39, Tamas K Lengyel wrote:
> On Tue, Jun 25, 2024 at 7:40 AM Jan Beulich wrote:
>>
>> On 25.06.2024 13:15, Tamas K Lengyel wrote:
>>> On Tue, Jun 25, 2024 at 5:17 AM Jan Beulich wrote:
On 21.06.2024 21:14, Tamas K Lengyel wrote:
> --- /dev/null
> +++ b/scripts/o
flight 186475 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186475/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-libvirt
On Tue, Jun 25, 2024 at 9:15 AM Jan Beulich wrote:
>
> On 25.06.2024 14:40, Tamas K Lengyel wrote:
> > On Tue, Jun 25, 2024 at 7:52 AM Jan Beulich wrote:
> >>
> >> On 25.06.2024 13:12, Tamas K Lengyel wrote:
> >>> On Tue, Jun 25, 2024 at 2:00 AM Jan Beulich wrote:
>
> On 24.06.2024 23:
On Tue, Jun 25, 2024 at 9:18 AM Jan Beulich wrote:
>
> On 25.06.2024 14:39, Tamas K Lengyel wrote:
> > On Tue, Jun 25, 2024 at 7:40 AM Jan Beulich wrote:
> >>
> >> On 25.06.2024 13:15, Tamas K Lengyel wrote:
> >>> On Tue, Jun 25, 2024 at 5:17 AM Jan Beulich wrote:
>
> On 21.06.2024 21:
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V13:
- redefine mfn_to_page() and mfn_to_page().
- add inclusion of after rebasing on top of staging.
---
Changes in V8-V12:
- Nothing changed only rebase.
---
Changes in V7:
- update argument type of maddr_to_virt() functi
The following generic functions were introduced:
* test_bit
* generic__test_and_set_bit
* generic__test_and_clear_bit
* generic__test_and_change_bit
These functions and macros can be useful for architectures
that don't have corresponding arch-specific instructions.
Also, the patch introduces the
This patch doesn't represent a strict lower bound for GCC and
GNU Binutils; rather, these versions are specifically employed by
the Xen RISC-V container and are anticipated to undergo continuous
testing. Older GCC and GNU Binutils would work,
but this is not a guarantee.
While it is feasible to ut
Signed-off-by: Oleksii Kurochko
Reviewed-by: Jan Beulich
---
Changes in V13:
- implement get_upper_mfn_bound() as BUG_ON("unimplemented")
- drop the footer after R-by as Andrew's patch series were merged to staging.
---
Changes in V5-V12:
- Nothing changed. Only rebase.
- Add the footer af
constant_test_bit() is functionally the same as generic_test_bit(),
so constant_test_bit() can be dropped and replaced with
generic_test_bit().
Signed-off-by: Oleksii Kurochko
---
Changes in V13:
- new patch ( this patch is dependent on
xen: introduce generic non-atomic test_*bit() )
---
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V13:
- drop no_irq_type because of the patch series ( [PATCH for-4.19 0/2]
arch/irq: Untangle no_irq_type )
which was merged to staging.
- Drop unnessary stubs after rebasing on top of staging ( [PATCH for-4.19 0/2]
arch/
Taken from Linux-6.4.0-rc1
Xen's bitops.h consists of several Linux's headers:
* linux/arch/include/asm/bitops.h:
* The following function were removed as they aren't used in Xen:
* test_and_set_bit_lock
* clear_bit_unlock
* __clear_bit_unlock
* The following functions
***
I think that I need to write a separate email requesting approval for this patch
series to be included in Xen 4.19. Most of the patches are RISC-V specific,
so there is a low risk of breaking anything else.
There is only one patch that touches common or arch-specific files, and it
doesn't intro
The .insn directive appears to check that the byte pattern is a known
extension, where .4byte doesn't.
The following compilation error occurs:
./arch/riscv/include/asm/processor.h: Assembler messages:
./arch/riscv/include/asm/processor.h:70: Error: unrecognized opcode
`0x010F'
In case of
RISC-V does a conditional toolchain for the Zbb extension
(xen/arch/riscv/rules.mk), but unconditionally uses the
ANDN instruction in emulate_xchg_1_2().
Fixes: 51dabd6312c ("xen/riscv: introduce cmpxchg.h")
Suggested-by: Andrew Cooper
Signed-off-by: Oleksii Kurochko
---
Changes in V13:
- ne
During Gitlab CI randconfig job for RISC-V failed witn an error:
common/trace.c:57:22: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '__read_mostly'
57 | static u32 data_size __read_mostly;
Signed-off-by: Oleksii Kurochko
---
Changes in V13:
-
On Tue, 2024-06-25 at 10:26 +0200, Jan Beulich wrote:
> On 25.06.2024 10:10, Oleksii wrote:
> > On Tue, 2024-06-25 at 09:57 +0200, Jan Beulich wrote:
> > > Pull in the gcc14 build fix there.
> > >
> > > Signed-off-by: Jan Beulich
> > > ---
> > > Probably nice to reference a gcc14-clean MiniOS tre
On 25/06/2024 3:02 pm, Oleksii wrote:
> On Tue, 2024-06-25 at 10:26 +0200, Jan Beulich wrote:
>> On 25.06.2024 10:10, Oleksii wrote:
>>> On Tue, 2024-06-25 at 09:57 +0200, Jan Beulich wrote:
Pull in the gcc14 build fix there.
Signed-off-by: Jan Beulich
---
Probably nice to
flight 186486 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186486/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 25.06.2024 15:51, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> Acked-by: Jan Beulich
> ---
> Changes in V13:
> - redefine mfn_to_page() and mfn_to_page().
DYM page_to_mfn() here as one of the two?
> +/* Convert between machine frame numbers and page-info structures. */
> +#de
On 25.06.2024 15:51, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> Reviewed-by: Jan Beulich
> ---
> Changes in V13:
> - implement get_upper_mfn_bound() as BUG_ON("unimplemented")
Odd, patch 4 also says this and also does so.
Jan
On 25.06.2024 15:51, Oleksii Kurochko wrote:
> During Gitlab CI randconfig job for RISC-V failed witn an error:
> common/trace.c:57:22: error: expected '=', ',', ';', 'asm' or
> '__attribute__' before '__read_mostly'
>57 | static u32 data_size __read_mostly;
>
>
On 25.06.2024 15:51, Oleksii Kurochko wrote:
> The .insn directive appears to check that the byte pattern is a known
> extension, where .4byte doesn't.
Support for specifying "raw" insns was added only in 2.38. Moving away
from .insn has other downsides (which may or may not matter here, but
that
On 25.06.2024 15:51, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/cmpxchg.h
> +++ b/xen/arch/riscv/include/asm/cmpxchg.h
> @@ -18,6 +18,20 @@
> : "r" (new) \
> : "memory" );
>
> +/*
> + * Binutils < 2.37 doesn't understand ANDN. If the toolchain is too
> +ld, form
On 25.06.2024 15:51, Oleksii Kurochko wrote:
> constant_test_bit() is functionally the same as generic_test_bit(),
> so constant_test_bit() can be dropped and replaced with
> generic_test_bit().
>
> Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
(Didn't I ask for this to be done, so perh
On 25.06.2024 15:40, Tamas K Lengyel wrote:
> On Tue, Jun 25, 2024 at 9:15 AM Jan Beulich wrote:
>>
>> On 25.06.2024 14:40, Tamas K Lengyel wrote:
>>> On Tue, Jun 25, 2024 at 7:52 AM Jan Beulich wrote:
On 25.06.2024 13:12, Tamas K Lengyel wrote:
> On Tue, Jun 25, 2024 at 2:00 AM Jan
On 25.06.2024 15:42, Tamas K Lengyel wrote:
> On Tue, Jun 25, 2024 at 9:18 AM Jan Beulich wrote:
>>
>> On 25.06.2024 14:39, Tamas K Lengyel wrote:
>>> On Tue, Jun 25, 2024 at 7:40 AM Jan Beulich wrote:
On 25.06.2024 13:15, Tamas K Lengyel wrote:
> On Tue, Jun 25, 2024 at 5:17 AM Jan
On 25.06.2024 12:14, Alessandro Zucchelli wrote:
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -660,14 +660,15 @@ long do_xen_version(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
>
> case XENVER_guest_handle:
> {
> +struct domain *d = current->domain;
Can a (new
On Tue, Jun 25, 2024 at 10:56 AM Jan Beulich wrote:
>
> On 25.06.2024 15:40, Tamas K Lengyel wrote:
> > On Tue, Jun 25, 2024 at 9:15 AM Jan Beulich wrote:
> >>
> >> On 25.06.2024 14:40, Tamas K Lengyel wrote:
> >>> On Tue, Jun 25, 2024 at 7:52 AM Jan Beulich wrote:
>
> On 25.06.2024 13
Update ECLAIR configuration to take into account the deviations
agreed during the MISRA meetings.
While doing this, remove the obsolete "Set [123]" comments.
Signed-off-by: Federico Serafini
---
.../eclair_analysis/ECLAIR/deviations.ecl | 93 +--
docs/misra/deviations.rst
On Fri, Jun 21, 2024 at 03:38:36PM +, Anthony PERARD wrote:
> On Mon, Jun 03, 2024 at 03:59:18PM +0100, Matthew Barnes wrote:
> > diff --git a/tools/misc/xen-hvmcrash.c b/tools/misc/xen-hvmcrash.c
> > index 1d058fa40a47..8ef1beb388f8 100644
> > --- a/tools/misc/xen-hvmcrash.c
> > +++ b/tools/mi
On Tue, 2024-06-25 at 16:22 +0200, Jan Beulich wrote:
> On 25.06.2024 15:51, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > Acked-by: Jan Beulich
> > ---
> > Changes in V13:
> > - redefine mfn_to_page() and mfn_to_page().
>
> DYM page_to_mfn() here as one of the two?
Yes, one o
On 25.06.2024 17:20, Tamas K Lengyel wrote:
> On Tue, Jun 25, 2024 at 10:56 AM Jan Beulich wrote:
>>
>> On 25.06.2024 15:40, Tamas K Lengyel wrote:
>>> On Tue, Jun 25, 2024 at 9:15 AM Jan Beulich wrote:
On 25.06.2024 14:40, Tamas K Lengyel wrote:
> On Tue, Jun 25, 2024 at 7:52 AM Ja
On Tue, 2024-06-25 at 16:24 +0200, Jan Beulich wrote:
> On 25.06.2024 15:51, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > Reviewed-by: Jan Beulich
> > ---
> > Changes in V13:
> > - implement get_upper_mfn_bound() as BUG_ON("unimplemented")
>
> Odd, patch 4 also says this an
On Tue, 2024-06-25 at 16:25 +0200, Jan Beulich wrote:
> On 25.06.2024 15:51, Oleksii Kurochko wrote:
> > During Gitlab CI randconfig job for RISC-V failed witn an error:
> > common/trace.c:57:22: error: expected '=', ',', ';', 'asm' or
> > '__attribute__' before
> > '
On Tue, 2024-06-25 at 16:51 +0200, Jan Beulich wrote:
> On 25.06.2024 15:51, Oleksii Kurochko wrote:
> > constant_test_bit() is functionally the same as generic_test_bit(),
> > so constant_test_bit() can be dropped and replaced with
> > generic_test_bit().
> >
> > Signed-off-by: Oleksii Kurochko
flight 186490 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186490/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 10b4bb8d6d0c515ed9663691aea3684be8f7b0fc
baseline version:
ovmf be38c01da2dd949e0a6f8
On Tue, 2024-06-25 at 16:45 +0200, Jan Beulich wrote:
> On 25.06.2024 15:51, Oleksii Kurochko wrote:
> > The .insn directive appears to check that the byte pattern is a
> > known
> > extension, where .4byte doesn't.
>
> Support for specifying "raw" insns was added only in 2.38. Moving
> away
> fro
On Tue, 2024-06-25 at 16:49 +0200, Jan Beulich wrote:
> On 25.06.2024 15:51, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/include/asm/cmpxchg.h
> > +++ b/xen/arch/riscv/include/asm/cmpxchg.h
> > @@ -18,6 +18,20 @@
> > : "r" (new) \
> > : "memory" );
> >
> > +/*
> > + * Binut
On Tue, 2024-06-25 at 09:57 +0200, Jan Beulich wrote:
> Pull in the gcc14 build fix there.
>
> Signed-off-by: Jan Beulich
Release-Acked-by: Oleksii Kurochko
~ Oleksii
> ---
> Probably nice to reference a gcc14-clean MiniOS tree from what is
> going
> to be 4.19.
>
> --- a/Config.mk
> +++ b/Co
There are two issues. First, pi_test_and_clear_on() pulls the cache-line to
the CPU and dirties it even if there's nothing outstanding, but the final
for_each_set_bit() is O(256) when O(8) would do, and would avoid multiple
atomic updates to the same IRR word.
Rewrite it from scratch, explaining
... and use it in self-tests.h.
This is intended to replace constructs such as __bitop_bad_size(). It
produces a better diagnostic, and is MISRA-friendly.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC:
for_each_set_bit() is currently horribly inefficient for how we commonly use
it. See patch 4 for details.
Andrew Cooper (6):
x86/vmx: Rewrite vmx_sync_pir_to_irr() to be more efficient
xen/bitops: Rename for_each_set_bit() to bitmap_for_each()
xen/macros: Introduce BUILD_ERROR()
xen/bitop
The prior version (renamed to bitmap_for_each()) was inefficeint when used
over a scalar, but this is the more common usage even before accounting for
the many opencoded forms.
Introduce a new version which operates on scalars only and does so without
spilling them to memory. This in turn require
... which is better optimised for scalar values, rather than using the
arbitrary-sized bitmap helpers.
For ARM32:
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-16 (-16)
Function old new delta
vgic_set_irqs_pending284 268
In all 3 examples, we're iterating over a scaler. No caller can pass the
COMPRESSED flag in, so the upper bound of 63, as opposed to 64, doesn't
matter.
This alone produces:
add/remove: 0/0 grow/shrink: 0/4 up/down: 0/-161 (-161)
Function old new del
The current implementation wants to take an in-memory bitmap. However, all
ARM callers and all-but-1 x86 callers spill a scalar to the stack in order to
use the "generic arbitrary bitmap" helpers under the hood.
This functions, but it's far from ideal.
Rename the construct and move it into bitma
On 2024-03-19 08:45, Jan Beulich wrote:
On 19.03.2024 04:34, Stefano Stabellini wrote:
On Mon, 18 Mar 2024, Jan Beulich wrote:
On 16.03.2024 01:43, Stefano Stabellini wrote:
On Fri, 15 Mar 2024, Jan Beulich wrote:
On 14.03.2024 23:59, Stefano Stabellini wrote:
On Mon, 11 Mar 2024, Simone Bal
On 2024-03-12 09:16, Jan Beulich wrote:
On 11.03.2024 09:59, Simone Ballarin wrote:
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -258,18 +258,20 @@ $(obj)/asm-macros.i: CFLAGS-y += -P
$(objtree)/arch/x86/include/asm/asm-macros.h: $(obj)/asm-macros.i
$(src)/Makefile
$(cal
On 03/06/2024 3:59 pm, Matthew Barnes wrote:
> xen-hvmcrash would previously save records, overwrite the instruction
> pointer with a bogus value, and then restore them to crash a domain
> just enough to cause the guest OS to memdump.
>
> This approach is found to be unreliable when tested on a gue
On 25/06/2024 3:49 pm, Jan Beulich wrote:
> On 25.06.2024 15:51, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/include/asm/cmpxchg.h
>> +++ b/xen/arch/riscv/include/asm/cmpxchg.h
>> @@ -18,6 +18,20 @@
>> : "r" (new) \
>> : "memory" );
>>
>> +/*
>> + * Binutils < 2.37 doesn't u
flight 186480 xen-unstable real [real]
flight 186496 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186480/
http://logs.test-lab.xenproject.org/osstest/logs/186496/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
afaict we're in decent state to move this series into mm-stable. I've
tagged the following issues:
https://lkml.kernel.org/r/80532f73e52e2c21fdc9aac7bce24aefb76d11b0.ca...@linux.intel.com
https://lkml.kernel.org/r/30b5d493-b7c2-4e63-86c1-dcc73d21d...@redhat.com
Have these been addressed and are
flight 186485 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186485/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186462
test-amd64-amd64-xl-qemut-win7-amd64
1 - 100 of 125 matches
Mail list logo
