On 14.12.2023 23:04, Stefano Stabellini wrote:
> On Thu, 14 Dec 2023, Jan Beulich wrote:
>> On 14.12.2023 13:07, Simone Ballarin wrote:
>>> --- a/docs/misra/safe.json
>>> +++ b/docs/misra/safe.json
>>> @@ -28,6 +28,14 @@
>>> },
>>> {
>>> "id": "SAF-3-safe",
>>> +
On 2023/12/15 06:49, Stefano Stabellini wrote:
> On Thu, 14 Dec 2023, Roger Pau Monné wrote:
>> On Thu, Dec 14, 2023 at 10:58:24AM +0100, Jan Beulich wrote:
>>> On 14.12.2023 10:55, Roger Pau Monné wrote:
On Thu, Dec 14, 2023 at 08:55:45AM +, Chen, Jiqian wrote:
> On 2023/12/13 15:03,
flight 184133 xen-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184133/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail blocked in 184105
test-armhf-armhf-libvirt 16
Introduce static-shmem.h to asm-generic as a prerequisite for moving
ARM's bootfdt.c into xen/common.
Signed-off-by: Shawn Anastasio
---
xen/arch/ppc/include/asm/Makefile | 1 +
xen/include/asm-generic/static-shmem.h | 12
2 files changed, 13 insertions(+)
create mode 100644
Hello all,
This series enables the Xen boot time allocator on Power by parsing
the available memory regions from the firmware-provided device tree.
As suggested during review of v1, this is now accomplished by moving
Arm's bootfdt.c into xen/common, along with a few modifications to
adapt it to
The early_print_info routine in bootfdt.c incorrectly stores the result
of a call to fdt_num_mem_rsv() in an unsigned int, which results in the
negative error code being interpreted incorrectly in a subsequent loop
in the case where the device tree does not contain any memory reserve
map entries.
Move PPC off the asm-generic setup.h and enable usage of bootfdt for
populating the boot info struct from the firmware-provided device tree.
Also enable the Xen boot page allocator.
Includes minor changes to bootfdt.c's boot_fdt_info() to tolerate the
scenario in which the FDT overlaps a reserved
In the initial mm-radix implementation, the in-memory partition and
process tables required to configure the MMU were allocated statically
since the boot allocator was not yet available.
Now that it is, allocate these tables at runtime and bump the size of
the Process Table to its maximum
Move Arm's bootfdt.c to xen/common so that it can be used by other
device tree architectures like PPC and RISCV. Only a minor change to
conditionalize a call to a function only available on EFI-supporting
targets was made to the code itself.
Suggested-by: Julien Grall
Signed-off-by: Shawn
Introduce setup.h to asm-generic based off of ARM's to define all
stubs necessary to compile bootfdt.c
Signed-off-by: Shawn Anastasio
---
xen/arch/ppc/include/asm/Makefile | 1 +
xen/arch/ppc/include/asm/setup.h | 6 --
xen/include/asm-generic/setup.h | 148 ++
Now that we have common code building, there's no need to keep the old
itoa64+debug print function in mm-radix.c
Signed-off-by: Shawn Anastasio
---
xen/arch/ppc/mm-radix.c | 58 +
1 file changed, 12 insertions(+), 46 deletions(-)
diff --git
Hi Jan,
On 12/4/23 1:58 AM, Jan Beulich wrote:
> A standalone patch with this title was sent earlier. What's their
> interrelation?
>
I had intended to prefix this patch with 'RESEND' to clarify that it is
the same as the one previously sent, but seem to have forgotten. My
apologies! In any
Hi Julien,
Thank you for the feedback. Most of your points will be addressed by
following your suggestion of moving ARM's bootfdt.c to common, but I
wanted to respond with a few points of clarification.
On 12/1/23 5:23 PM, Julien Grall wrote:
> * fdt_get_mem_rsv_paddr(), this is part of the DT
flight 184142 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184142/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3ce5f2d445e51efe2aebaa227a055e5c8522d00b
baseline version:
ovmf
So we have recently discovered an overlooked interaction with VT-x.
Immediately before VMENTER and after VMEXIT, CR2 is live with the
*guest* CR2. Regardless of if the guest uses FRED or not, this is guest
state and SHOULD NOT be corrupted. Furthermore, host state MUST NOT leak
into the guest.
On 14/12/2023 4:35 pm, Federico Serafini wrote:
> Introduce function type bug_fn_nonconst_t (as opposed to bug_fn_t)
> to validate the argument passed to run_in_exception_handle().
>
> Place the definition of bug_fn_nonconst_t before of asm/bug.h inclusion
> so that arch-specific implementations
flight 184132 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184132/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 8 xen-boot fail REGR. vs. 183973
build-i386-pvops
On Thu, 14 Dec 2023, Roger Pau Monné wrote:
> On Thu, Dec 14, 2023 at 10:58:24AM +0100, Jan Beulich wrote:
> > On 14.12.2023 10:55, Roger Pau Monné wrote:
> > > On Thu, Dec 14, 2023 at 08:55:45AM +, Chen, Jiqian wrote:
> > >> On 2023/12/13 15:03, Jan Beulich wrote:
> > >>> On 13.12.2023 03:47,
On Thu, 14 Dec 2023, Julien Grall wrote:
> Hi,
>
> On 13/12/2023 14:02, Nicola Vetrini wrote:
> > On 2023-12-12 16:49, Julien Grall wrote:
> > > Hi,
> > >
> > > On 11/12/2023 12:32, Julien Grall wrote:
> > > > Hi,
> > > >
> > > > On 11/12/2023 10:30, Nicola Vetrini wrote:
> > > > > The branches
On Thu, 14 Dec 2023, Federico Serafini wrote:
> Introduce function type bug_fn_nonconst_t (as opposed to bug_fn_t)
> to validate the argument passed to run_in_exception_handle().
>
> Place the definition of bug_fn_nonconst_t before of asm/bug.h inclusion
> so that arch-specific implementations of
On Thu, 14 Dec 2023, Jan Beulich wrote:
> On 14.12.2023 13:07, Simone Ballarin wrote:
> > --- a/docs/misra/safe.json
> > +++ b/docs/misra/safe.json
> > @@ -28,6 +28,14 @@
> > },
> > {
> > "id": "SAF-3-safe",
> > +"analyser": {
> > +
On Thu, 14 Dec 2023, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
> headline states:
> "A conversion shall not remove any const, volatile or _Atomic qualification
> from the type pointed to by a pointer".
>
> Remove
On Thu, 14 Dec 2023, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
> headline states:
> "A conversion shall not remove any const, volatile or _Atomic qualification
> from the type pointed to by a pointer".
>
> Fix
On Thu, 14 Dec 2023, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
> headline states:
> "A conversion shall not remove any const, volatile or _Atomic qualification
> from the type pointed to by a pointer".
>
> Add
On Thu, 14 Dec 2023, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
> headline states:
> "A conversion shall not remove any const, volatile or _Atomic qualification
> from the type pointed to by a pointer".
>
> Add
On Thu, 14 Dec 2023, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
> headline states:
> "A conversion shall not remove any const, volatile or _Atomic qualification
> from the type pointed to by a pointer".
>
> Add
On Thu, 14 Dec 2023, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
> headline states:
> "A conversion shall not remove any const, volatile or _Atomic qualification
> from the type pointed to by a pointer".
>
> Add
On Thu, 14 Dec 2023, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
> headline states:
> "A conversion shall not remove any const, volatile or _Atomic qualification
> from the type pointed to by a pointer".
>
> Add
On Thu, 14 Dec 2023, Nicola Vetrini wrote:
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Thu, 14 Dec 2023, Nicola Vetrini wrote:
> Use of the proper helper macro also resolves a violation
> of MISRA C Rule 11.9.
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Thu, 14 Dec 2023, Nicola Vetrini wrote:
> Resolves a violation of MISRA C Rule 11.9.
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Thu, 14 Dec 2023, Nicola Vetrini wrote:
> Resolves violations of MISRA C Rule 11.9.
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Thu, 14 Dec 2023, Nicola Vetrini wrote:
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Thu, 14 Dec 2023, Julien Grall wrote:
> Hi George,
>
> On 14/12/2023 14:15, George Dunlap wrote:
> > But I do think that it's fair to ask Julien to think about a suitable
> > wording, since the comment is in a sense to remind him (or other ARM
> > maintainers) what's needed, and since the
flight 184131 xen-unstable real [real]
flight 184140 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184131/
http://logs.test-lab.xenproject.org/osstest/logs/184140/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Hi George,
On 14/12/2023 14:15, George Dunlap wrote:
But I do think that it's fair to ask Julien to think about a suitable
wording, since the comment is in a sense to remind him (or other ARM
maintainers) what's needed, and since the eventual solution will be
something to do with the ARM code
On Thu, 13 Dec 2023, Roger Pau Monne wrote:
> Introduce a new gitlab tests for livepatching, using livepatch-build-tools,
> which better reflects how downstreams build live patches rather than the
> in-tree tests.
>
> The tests applies the dummy in-tree patch example, checks that the patch is
>
flight 184138 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184138/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7f5e75895bd6bbfbde191fb8458d324033f76c57
baseline version:
ovmf
flight 184129 linux-5.4 real [real]
flight 184137 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184129/
http://logs.test-lab.xenproject.org/osstest/logs/184137/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/mm.h
> +++ b/xen/arch/riscv/include/asm/mm.h
> @@ -3,10 +3,271 @@
> #ifndef _ASM_RISCV_MM_H
> #define _ASM_RISCV_MM_H
>
> +#include
> +#include
> +#include
> +
> +#include
> #include
>
> -#define
On 14.12.2023 13:07, Simone Ballarin wrote:
> --- a/docs/misra/safe.json
> +++ b/docs/misra/safe.json
> @@ -28,6 +28,14 @@
> },
> {
> "id": "SAF-3-safe",
> +"analyser": {
> +"eclair": "MC3R1.R11.8"
> +},
> +"name":
On 14.12.2023 13:07, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
> headline states:
> "A conversion shall not remove any const, volatile or _Atomic qualification
> from the type pointed to by a pointer".
>
> Remove
On 14.12.2023 13:07, Simone Ballarin wrote:
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -300,8 +300,8 @@ static multiboot_info_t *mbi2_reloc(uint32_t mbi_in,
> uint32_t video_out)
> const struct vesa_mode_info *mi;
>
> video =
On Thu, 2023-12-14 at 17:24 +0100, Jan Beulich wrote:
> On 24.11.2023 11:30, Oleksii Kurochko wrote:
> > The following issue occurs on RISC-V platforms:
> > drivers/char/serial.c: In function 'serial_tx_interrupt':
> > drivers/char/serial.c:88:9: error: implicit declaration of function
> >
On 14.12.2023 13:07, Simone Ballarin wrote:
> --- a/xen/include/acpi/acmacros.h
> +++ b/xen/include/acpi/acmacros.h
> @@ -116,7 +116,7 @@
> #define ACPI_PTR_TO_PHYSADDR(i) ACPI_TO_INTEGER(i)
>
> #ifndef ACPI_MISALIGNMENT_NOT_SUPPORTED
> -#define ACPI_COMPARE_NAME(a,b)
Introduce function type bug_fn_nonconst_t (as opposed to bug_fn_t)
to validate the argument passed to run_in_exception_handle().
Place the definition of bug_fn_nonconst_t before of asm/bug.h inclusion
so that arch-specific implementations of run_in_exception_handler() can
use it (and move
On 14.12.2023 13:07, Simone Ballarin wrote:
> --- a/xen/common/version.c
> +++ b/xen/common/version.c
> @@ -178,7 +178,7 @@ void __init xen_build_init(void)
> if ( [1] >= __note_gnu_build_id_end )
> return;
>
> -sz = (void *)__note_gnu_build_id_end - (void *)n;
> +sz =
flight 184136 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184136/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 59a952d9ab007fda9f7a66418782c8257d3c917f
baseline version:
ovmf
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> The following issue occurs on RISC-V platforms:
> drivers/char/serial.c: In function 'serial_tx_interrupt':
> drivers/char/serial.c:88:9: error: implicit declaration of function
> 'cpu_relax' [-Werror=implicit-function-declaration]
>88 |
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
With an empty description it is hard to judge whether this is really needed.
I would sincerely hope we can get away without. Note how there already a few
struct xen_domctl_* forward declarations there, which - if the
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
I think though that this would make sense to fold into patch 4, which is
where the relevant (stub) structure appears.
Jan
> --- a/xen/include/public/pmu.h
> +++ b/xen/include/public/pmu.h
>
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/processor.h
> +++ b/xen/arch/riscv/include/asm/processor.h
> @@ -12,6 +12,9 @@
>
> #ifndef __ASSEMBLY__
>
> +/* TODO: need to be implemeted */
> +#define get_processor_id() 0
Please don't re-introduce this - it
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
I wonder though ...
> --- a/xen/arch/riscv/include/asm/page.h
> +++ b/xen/arch/riscv/include/asm/page.h
> @@ -6,6 +6,7 @@
> #ifndef __ASSEMBLY__
>
> #include
> +#include
> #include
>
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/current.h
> +++ b/xen/arch/riscv/include/asm/current.h
> @@ -3,6 +3,22 @@
> #ifndef __ASM_CURRENT_H
> #define __ASM_CURRENT_H
>
> +#include
> +#include
> +
> +#ifndef __ASSEMBLY__
> +
> +struct vcpu;
I don't
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> Also the patchs adds some helpful macros.
In how far they're (going to be) helpful is hard to tell without uses
and without some suitable comments.
> --- a/xen/arch/riscv/include/asm/config.h
> +++ b/xen/arch/riscv/include/asm/config.h
> @@ -77,12
On 14.12.2023 16:28, Roger Pau Monné wrote:
> On Thu, Dec 14, 2023 at 02:57:11PM +0100, Jan Beulich wrote:
>> On 14.12.2023 14:47, Roger Pau Monné wrote:
>>> On Thu, Dec 14, 2023 at 12:55:22PM +0100, Jan Beulich wrote:
On 14.12.2023 11:17, Roger Pau Monne wrote:
> ---
On Thu, Dec 14, 2023 at 02:57:11PM +0100, Jan Beulich wrote:
> On 14.12.2023 14:47, Roger Pau Monné wrote:
> > On Thu, Dec 14, 2023 at 12:55:22PM +0100, Jan Beulich wrote:
> >> On 14.12.2023 11:17, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/setup.c
> >>> +++ b/xen/arch/x86/setup.c
> >>> @@
On 14.12.2023 16:20, Roger Pau Monné wrote:
> On Thu, Dec 14, 2023 at 02:53:13PM +0100, Jan Beulich wrote:
>> On 14.12.2023 14:37, Roger Pau Monné wrote:
>>> On Thu, Dec 14, 2023 at 12:18:13PM +0100, Jan Beulich wrote:
On 14.12.2023 11:17, Roger Pau Monne wrote:
> The minimal function
On Thu, Dec 14, 2023 at 02:53:13PM +0100, Jan Beulich wrote:
> On 14.12.2023 14:37, Roger Pau Monné wrote:
> > On Thu, Dec 14, 2023 at 12:18:13PM +0100, Jan Beulich wrote:
> >> On 14.12.2023 11:17, Roger Pau Monne wrote:
> >>> The minimal function size requirements for livepatch are either 5 bytes
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/event.h
> @@ -0,0 +1,34 @@
> +#ifndef __ASM_RISCV_EVENT_H__
> +#define __ASM_RISCV_EVENT_H__
> +
> +void vcpu_mark_events_pending(struct vcpu *v);
> +
> +static inline int
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/time.h
> @@ -0,0 +1,19 @@
> +#ifndef __ASM_RISCV_TIME_H__
> +#define __ASM_RISCV_TIME_H__
> +
> +#include
> +#include
> +
> +struct vcpu;
> +
> +/* TODO: implement */
> +static inline void
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/regs.h
> @@ -0,0 +1,26 @@
> +#ifndef __ARM_RISCV_REGS_H__
> +#define __ARM_RISCV_REGS_H__
> +
> +#ifndef __ASSEMBLY__
> +
> +#include
> +#include
Does one of these bring in asm/processor.h, for ...
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> +static inline int guest_physmap_mark_populate_on_demand(struct domain *d,
> unsigned long gfn,
> +unsigned int order)
> +{
> +BUG();
> +return 1;
> +}
This one I actually don't think
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/p2m.h
> @@ -0,0 +1,105 @@
> +#ifndef __ASM_RISCV_P2M_H__
> +#define __ASM_RISCV_P2M_H__
> +
> +#include
> +
> +#define paddr_bits PADDR_BITS
> +
> +/*
> + * List of possible type for each page in the
On Thu, Dec 14, 2023 at 8:51 AM Jan Beulich wrote:
>
> On 14.12.2023 09:32, Julien Grall wrote:
> > Hi Jan,
> >
> > On 14/12/2023 07:53, Jan Beulich wrote:
> >> On 14.12.2023 03:05, Stefano Stabellini wrote:
> >>> On Wed, 13 Dec 2023, Jan Beulich wrote:
> On 11.12.2023 10:14, Nicola Vetrini
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> ---
> Changes in V2:
> - add ifdef CONFIG_HAS_DEVICE_TREE for things that shouldn't be
> in case !CONFIG_HAS_DEVICE_TREE
Is there going to be a RISC-V build without this enabled (selected)? If
not, I'd
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/guest_access.h
> @@ -0,0 +1,29 @@
> +#ifndef __ASM_RISCV_GUEST_ACCESS_H__
> +#define __ASM_RISCV_GUEST_ACCESS_H__
> +
> +#include
> +
> +unsigned long raw_copy_to_guest(void *to, const void *from,
On 14.12.2023 14:47, Roger Pau Monné wrote:
> On Thu, Dec 14, 2023 at 12:55:22PM +0100, Jan Beulich wrote:
>> On 14.12.2023 11:17, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -58,6 +58,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
On 14.12.2023 14:37, Roger Pau Monné wrote:
> On Thu, Dec 14, 2023 at 12:18:13PM +0100, Jan Beulich wrote:
>> On 14.12.2023 11:17, Roger Pau Monne wrote:
>>> The minimal function size requirements for livepatch are either 5 bytes (for
>>> jmp) or 9 bytes (for endbr + jmp) on x86, and always 4
On Thu, Dec 14, 2023 at 12:55:22PM +0100, Jan Beulich wrote:
> On 14.12.2023 11:17, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -58,6 +58,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /* opt_nosmp: If true, secondary
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
On Thu, Dec 14, 2023 at 12:18:13PM +0100, Jan Beulich wrote:
> On 14.12.2023 11:17, Roger Pau Monne wrote:
> > The minimal function size requirements for livepatch are either 5 bytes (for
> > jmp) or 9 bytes (for endbr + jmp) on x86, and always 4 bytes on Arm. Ensure
> > that distance between
flight 184135 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184135/
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
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Did you write this code from scratch? If not, you need to at least point
out the origin. But: None of this looks RISC-V specific, so shouldn't it
instead be put under xen/lib/, as a fallback implementation for arch-es
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
If this is enough for the time being, so be it:
Acked-by: Jan Beulich
Jan
On 14.12.2023 11:17, Roger Pau Monne wrote:
> Introduce a basic livepatch test using the interface to run self modifying
> tests. The introduced test relies on changing a function from returning false
> to returning true.
>
> To simplify the burden of keeping a patch that can be provided to
>
On 14.12.2023 13:07, Simone Ballarin wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -292,6 +292,18 @@ constant expressions are required.\""
> # Series 11
> #
>
> +-doc_begin="Violations caused by container_of are
On 14.12.2023 13:07, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
> headline states:
> "A conversion shall not remove any const, volatile or _Atomic
> qualification from the type pointed to by a pointer".
>
> This
From: Maria Celeste Cesario
The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
headline states:
"A conversion shall not remove any const, volatile or _Atomic qualification
from the type pointed to by a pointer".
In function __hvm_copy, the const qualifier is cast away to comply
From: Maria Celeste Cesario
The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
headline states:
"A conversion shall not remove any const, volatile or _Atomic qualification
from the type pointed to by a pointer".
Deviate use of macro container_of.
Deviate use of function
From: Maria Celeste Cesario
The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
headline states:
"A conversion shall not remove any const, volatile or _Atomic qualification
from the type pointed to by a pointer".
Remove unnecessary cast.
from is a const-qualified pointer to void
From: Maria Celeste Cesario
The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
headline states:
"A conversion shall not remove any const, volatile or _Atomic qualification
from the type pointed to by a pointer".
Add missing const qualifiers missing in casting.
There's no reason
From: Maria Celeste Cesario
The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
headline states:
"A conversion shall not remove any const, volatile or _Atomic qualification
from the type pointed to by a pointer".
Add missing const qualifiers in casts.
Macro get_mb2_data returns
From: Maria Celeste Cesario
The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
headline states:
"A conversion shall not remove any const, volatile or _Atomic qualification
from the type pointed to by a pointer".
Add missing const qualifiers in casts.
The variables are originally
From: Maria Celeste Cesario
The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
headline states:
"A conversion shall not remove any const, volatile or _Atomic
qualification from the type pointed to by a pointer".
This patch amends or removes casts that unnecessarily drop
const
From: Maria Celeste Cesario
The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
headline states:
"A conversion shall not remove any const, volatile or _Atomic qualification
from the type pointed to by a pointer".
Fix violation by adding missing const qualifier in cast.
From: Maria Celeste Cesario
The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
headline states:
"A conversion shall not remove any const, volatile or _Atomic qualification
from the type pointed to by a pointer".
Add volatile qualifiers missing in casts.
Arguments p and ptr are
From: Maria Celeste Cesario
The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
headline states:
"A conversion shall not remove any const, volatile or _Atomic qualification
from the type pointed to by a pointer".
Add missing const qualifiers in casts.
The variables are originally
On Mon, Dec 04, 2023 at 09:47:01AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Xen only supports modern CPUs even when running a 32-bit kernel, and it now
> requires a kernel built for a 64 byte (or larger) cache line:
>
> In file included from :
> In function 'xen_vcpu_setup',
>
On 14.12.2023 11:17, Roger Pau Monne wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -58,6 +58,7 @@
> #include
> #include
> #include
> +#include
>
> /* opt_nosmp: If true, secondary processors are ignored. */
> static bool __initdata opt_nosmp;
> @@ -1951,6 +1952,8
Hi all,
this series resolves violations of MISRA C:2012 Rule 11.9. After this series is
applied the rule has no violations on both ARM and x86.
Nicola Vetrini (5):
xen/hvm: use NULL as a null pointer constant
x86/ioapic: use NULL as a null pointer constant
xen/acpi: Use NULL as a null
Use of the proper helper macro also resolves a violation
of MISRA C Rule 11.9.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/hvm/dom0_build.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/dom0_build.c
Resolves violations of MISRA C Rule 11.9.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/io_apic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index d11c880544e6..dd25ba394301 100644
---
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/common/wait.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/common/wait.c b/xen/common/wait.c
index 86d3b15419db..cb6f5ff3c20a 100644
--- a/xen/common/wait.c
+++ b/xen/common/wait.c
@@ -125,7 +125,7 @@
Resolves a violation of MISRA C Rule 11.9.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/include/acpi/acmacros.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/acpi/acmacros.h b/xen/include/acpi/acmacros.h
index 86c503c20f3b..e7ca18e3dc66 100644
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/include/asm/hvm/irq.h | 2 +-
xen/include/public/hvm/save.h | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/include/asm/hvm/irq.h
b/xen/arch/x86/include/asm/hvm/irq.h
index
Pipeline #1106785576 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: cad6f9a4 (
https://gitlab.com/xen-project/xen/-/commit/cad6f9a4c12dd4d5cdb2620e3fe24727ee81c7ce
)
Commit Message: smp: move
On 14.12.2023 11:17, Roger Pau Monne wrote:
> The minimal function size requirements for livepatch are either 5 bytes (for
> jmp) or 9 bytes (for endbr + jmp) on x86, and always 4 bytes on Arm. Ensure
> that distance between functions entry points is always at least of the minimal
> required size
On 14.12.2023 11:40, GitLab wrote:
>
>
> Pipeline #1106780344 has failed!
>
> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> Branch: staging (
> https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>
> Commit: cad6f9a4 (
>
On 13.12.2023 17:10, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 14.4 whose
> headline states:
> "The controlling expression of an if statement and the controlling
> expression of an iteration-statement shall have essentially
1 - 100 of 126 matches
Mail list logo
