On 13.12.2023 14:51, Roger Pau Monne wrote:
> --- a/livepatch-build
> +++ b/livepatch-build
> @@ -25,6 +25,7 @@
> # script.
>
> SCRIPTDIR="$(readlink -f $(dirname $(type -p $0)))"
> +WORKDIR="$(readlink -f -- .)"
More for my own education than anything else: Isn't the (standard) pwd
utility in
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 wrote:
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/arm/include/asm/numa.h
@@ -2,8 +2,9 @@
#define __ARCH_ARM_NU
On Thu, Dec 14, 2023 at 07:08:32AM +, Chen, Jiqian wrote:
> On 2023/12/13 20:12, Roger Pau Monné wrote:
> > On Wed, Dec 13, 2023 at 03:31:21AM +, Chen, Jiqian wrote:
> >> On 2023/12/12 17:18, Roger Pau Monné wrote:
> >>> On Tue, Dec 12, 2023 at 06:34:27AM +, Chen, Jiqian wrote:
>
>
On 2023-12-14 08: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 wrote:
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/arm/include/asm/numa.h
@@ -2,8 +2,9 @@
#define __ARCH_ARM_NUMA_H
#in
On Thu, Dec 14, 2023 at 09:19:35AM +0100, Jan Beulich wrote:
> On 13.12.2023 14:51, Roger Pau Monne wrote:
> > --- a/livepatch-build
> > +++ b/livepatch-build
> > @@ -25,6 +25,7 @@
> > # script.
> >
> > SCRIPTDIR="$(readlink -f $(dirname $(type -p $0)))"
> > +WORKDIR="$(readlink -f -- .)"
>
>
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 wrote:
> --- a/xen/arch/arm/include/asm/numa.h
> +++ b/xen/a
On 2023-12-14 08:57, Jan Beulich wrote:
On 13.12.2023 15:44, Nicola Vetrini wrote:
On 2023-12-12 10:53, Jan Beulich wrote:
On 12.12.2023 10:12, Nicola Vetrini wrote:
On 2023-12-12 02:42, Stefano Stabellini wrote:
On Mon, 11 Dec 2023, Nicola Vetrini wrote:
The "return 0" after the swich state
Currently version.o is explicitly ignored as the file would change as a result
of the orignal and the patched build having possibly different dates, times or
changeset strings (by the patched build appending -dirty).
Fix such difference by exporting the date and time from the build script, so
that
On 2023/12/13 15:03, Jan Beulich wrote:
> On 13.12.2023 03:47, Chen, Jiqian wrote:
>> On 2023/12/12 17:30, Jan Beulich wrote:
>>> On 12.12.2023 07:49, Chen, Jiqian wrote:
On 2023/12/11 23:31, Roger Pau Monné wrote:
> On Mon, Dec 11, 2023 at 12:40:08AM +0800, Jiqian Chen wrote:
>> --- a
On 13.12.2023 12:44, Federico Serafini wrote:
> I have another question regarding Rule 5.6 ("A `typedef' name shall be
> a unique identifier"), this time for X86:
> the violations left [1] involve guest_intpte_t, guest_l1e_t and
> guest_l2e_t, which seem to be deliberately defined differently depen
On 2023/12/14 16:46, Roger Pau Monné wrote:
> On Thu, Dec 14, 2023 at 07:08:32AM +, Chen, Jiqian wrote:
>> On 2023/12/13 20:12, Roger Pau Monné wrote:
>>> On Wed, Dec 13, 2023 at 03:31:21AM +, Chen, Jiqian wrote:
On 2023/12/12 17:18, Roger Pau Monné wrote:
> On Tue, Dec 12, 2023 at
On 14.12.2023 09:55, Chen, Jiqian wrote:
> On 2023/12/13 15:03, Jan Beulich wrote:
>> On 13.12.2023 03:47, Chen, Jiqian wrote:
>>> On 2023/12/12 17:30, Jan Beulich wrote:
On 12.12.2023 07:49, Chen, Jiqian wrote:
> On 2023/12/11 23:31, Roger Pau Monné wrote:
>> On Mon, Dec 11, 2023 at 1
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 of the switch after a call to 'do_unexpected_trap'
cannot return, but there is one path that may r
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, Chen, Jiqian wrote:
> >> On 2023/12/12 17:30, Jan Beulich wrote:
> >>> On 12.12.2023 07:49, Chen, Jiqian wrote:
> On 2023/12/11 23:31, Roger Pau Monné 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, Chen, Jiqian wrote:
On 2023/12/12 17:30, Jan Beulich wrote:
> On 12.12.2023 07:49, Chen, Jiqian wrote:
>> On 2
On 14/12/23 09:57, Jan Beulich wrote:
On 13.12.2023 12:44, Federico Serafini wrote:
I have another question regarding Rule 5.6 ("A `typedef' name shall be
a unique identifier"), this time for X86:
the violations left [1] involve guest_intpte_t, guest_l1e_t and
guest_l2e_t, which seem to be delib
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, Chen, Jiqian wrote:
> On 2023/12/12 17:30, Jan Be
On 11.12.2023 13:23, Julien Grall wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2535,6 +2535,17 @@ pages) must also be specified via the tbuf_size
> parameter.
> ### tickle_one_idle_cpu
> > `= `
>
> +### pit-irq-works (x86)
> +> `=`
> +
> +> D
Hi,
On 14/12/2023 10:10, Jan Beulich wrote:
On 11.12.2023 13:23, Julien Grall wrote:
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2535,6 +2535,17 @@ pages) must also be specified via the tbuf_size
parameter.
### tickle_one_idle_cpu
> `= `
+### pit-
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
livepatch-build-tools, introduce two new files: one contain
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 for livepatch instruction replacement to be successf
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
applied correctly and then reverts and unloads it.
Signed
Introduce a helper to perform checks related to self modifying code, and start
by creating a simple test to check that alternatives have been applied.
Such test is hooked into the boot process and called just after alternatives
have been applied. In case of failure a message is printed, and the h
Hello,
The following series contains a misc set of fixes and improvements.
There's one improvement for the hypervisor to set function alignment for
livepatch builds in order to make sure there's always enough space in a
function to be live-patched.
Following patches attempt to introduce a set of
On 11.12.2023 13:23, Julien Grall wrote:
> From: Julien Grall
>
> Currently timer_irq_works() will wait the full 100ms before checking
> that pit0_ticks has been incremented at least 4 times.
>
> However, the bulk of the BIOS/platform should not have a buggy timer.
> So waiting for the full 100m
On 14.12.2023 11:14, Julien Grall wrote:
> On 14/12/2023 10:10, Jan Beulich wrote:
>> On 11.12.2023 13:23, Julien Grall wrote:
>>> --- a/xen/arch/x86/io_apic.c
>>> +++ b/xen/arch/x86/io_apic.c
>>> @@ -57,6 +57,14 @@ bool __initdata ioapic_ack_forced;
>>> int __read_mostly nr_ioapic_entries[MAX_IO
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 Bo
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 (
> https://gitlab.com/xen-project/hardware/xen
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
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 cpu
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 1817ca
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
---
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
--- a/xen/arch/
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 @@ stat
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 b/xen/arch/x86/hvm/dom0_build.c
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 point
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
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',
> inl
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 or
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".
Fix violation by adding missing const qualifier in cast.
Signed-off
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 and
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".
Add missing const qualifiers in casts.
Macro get_mb2_data returns v
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 a
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 t
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 ERR_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".
In function __hvm_copy, the const qualifier is cast away to comply w
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 pat
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 due
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
> liv
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 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
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 1
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 func
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: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 proc
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 bytes
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 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, unsig
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 re
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 w
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 p2
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 ne
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:
> --- /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 force_update
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 vcpu_event_delivery_is_enabled(
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 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 size
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
> >>> @@ -58
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:
> --- a/xen/arch/x86/setup.
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 +7
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 thin
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/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 wa
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:
> 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:
> 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 | c
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 b8a3eec88cc74bbfe7fb3
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 ( &n[1] >= __note_gnu_build_id_end )
> return;
>
> -sz = (void *)__note_gnu_build_id_end - (void *)n;
> +sz = (co
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 bug_fn_t
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) (*ACPI_CA
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
> > 'cpu_rel
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 = _p(vid
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 u
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 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 pfn_to_padd
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):
test-amd64-amd6
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 59a952d9ab007fda9f7a6
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
> ap
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 a
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 r
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 even
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:
> 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:
> 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:
> 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:
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
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 vola
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 miss
1 - 100 of 126 matches
Mail list logo
