On 26/06/24 03:59, Stefano Stabellini wrote:
On Tue, 25 Jun 2024, Federico Serafini wrote:
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
Thank you
On Wed, Jun 26, 2024 at 02:11:11PM +0800, Oliver Sang wrote:
> hi, Christoph Hellwig,
>
> On Mon, Jun 24, 2024 at 10:35:37AM +0200, Christoph Hellwig wrote:
> > This is odd to say at least. Any chance you can check the value
> > of /sys/block/$DEVICE/queue/rotational for the relevant device befor
hi, Christoph Hellwig,
On Mon, Jun 24, 2024 at 10:35:37AM +0200, Christoph Hellwig wrote:
> This is odd to say at least. Any chance you can check the value
> of /sys/block/$DEVICE/queue/rotational for the relevant device before
> and after this commit? And is this an ATA or NVMe SSD?
>
yeah, a
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
---
Changes in v2:
- keep sync between deviations.ecl and deviations.rst;
- use 'deliberate' tag for all
In case cpu_schedule_up() is failing, it needs to undo all externally
visible changes it has done before.
Reason is that cpu_schedule_callback() won't be called with the
CPU_UP_CANCELED notifier in case cpu_schedule_up() did fail.
Reported-by: Jan Beulich
Fixes: 207589dbacd4 ("xen/sched: move pe
flight 186499 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186499/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186465
test-amd64-amd64-xl-qemut-win7-amd64
On 26.06.24 00:43, Andrew Morton wrote:
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...@redh
flight 186505 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186505/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0333faf50e49d3b3ea2c624b4d403b405b3107a1
baseline version:
ovmf dc93ff8a5561a3085eeda
On Wed, Jun 26, 2024 at 10:10:49AM +0800, Oliver Sang wrote:
> I'm not sure I understand this test request. as in title, we see a good
> improvement of aim7 for 1122c0c1cc, and we didn't observe other issues for
> this commit.
The improvement suggests we are not sending cache flushes when we shoul
flight 186501 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186501/
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
hi, Christoph Hellwig,
On Tue, Jun 25, 2024 at 01:57:35AM -0700, Christoph Hellwig wrote:
> 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
On Mon, 24 Jun 2024, Michal Orzel wrote:
> Reflect the latest Xen support to be able to omit the host physical
> address for static shared memory regions, in which case the address will
> come from the Xen heap.
>
> Signed-off-by: Michal Orzel
Reviewed-by: Stefano Stabellini
> ---
> README.m
flight 186502 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186502/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf dc93ff8a5561a3085eeda9d4ac00d40545eb43cd
baseline version:
ovmf 84d8eb08e15e455826ef6
On Tue, 25 Jun 2024, Federico Serafini wrote:
> 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
Thank you! Many of these deviations are really
On Mon, 24 Jun 2024, Federico Serafini wrote:
> Hi Stefano,
>
> On 22/06/24 02:14, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > This patch adds a bunch of rules to rules.rst that are uncontroversial
> > and have zero violations in Xen. As such, they have been approved for
> > a
From: Stefano Stabellini
This patch adds a bunch of rules to rules.rst that are uncontroversial
and have zero violations in Xen. As such, they have been approved for
adoption.
All the ones that regard the standard library have the link to the
existing footnote in the notes.
Signed-off-by: Stefa
On Tue, 25 Jun 2024, Alessandro Zucchelli wrote:
> 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
On Tue, 25 Jun 2024, Alessandro Zucchelli wrote:
> 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
On Tue, 25 Jun 2024, Jan Beulich wrote:
> 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:
> > {
>
On Tue, 25 Jun 2024, Jan Beulich wrote:
> On 25.06.2024 02:54, Stefano Stabellini wrote:
> > On Mon, 24 Jun 2024, Federico Serafini wrote:
> >> Add break or pseudo keyword fallthrough to address violations of
> >> MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
> >> every swi
On Tue, 25 Jun 2024, Jan Beulich wrote:
> 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: Stefa
On Tue, 25 Jun 2024, Nicola Vetrini wrote:
> On 2024-06-21 02:18, Stefano Stabellini wrote:
> > On Mon, 16 Jun 2024, Nicola Vetrini wrote:
> > > MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> > > of macro parameters shall be enclosed in parentheses".
> > >
> > > The helper m
flight 186498 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186498/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 84d8eb08e15e455826ef66a4b1f1f61758cb9aba
baseline version:
ovmf 10b4bb8d6d0c515ed9663
This target enables integration into oss-fuzz. Changing invalid input return
to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the
missing __wrap_vsnprintf wrapper which is required for successful oss-fuzz
build.
Signed-off-by: Tamas K Lengyel
---
tools/fuzz/x86_instruction_
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-off-by: Tamas K Lengyel
---
scripts/oss-fuzz/build.sh | 23
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
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 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
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
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 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 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
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
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
... 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
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
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
... 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:
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
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
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 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
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: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
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: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 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: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 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
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 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
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 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 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: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: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:
> 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:
> 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:
> 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:
> 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
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 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
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
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:
-
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
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
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/
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() )
---
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
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
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
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:
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:
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 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
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 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 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 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 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 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 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 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 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
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.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
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
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 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
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
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
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 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 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
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
1 - 100 of 125 matches
Mail list logo
