On 15.12.2023 22:02, Stefano Stabellini wrote:
> On Fri, 15 Dec 2023, Jan Beulich wrote:
>> 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
On 15.12.2023 15:54, Roger Pau Monné wrote:
> On Wed, Jun 07, 2023 at 08:17:30AM +0200, Jan Beulich wrote:
>> While frame table setup, directmap init, and boot allocator population
>> respect all intended bounds, the logic passing memory to the heap
>> allocator which wasn't passed to the boot
Deviate typedef names that are delberately defined multiple times.
Update docs/misra/deviations.rst accordingly.
Tag Rule 5.6 as clean.
Signed-off-by: Federico Serafini
---
Changes in v2:
- fixed typo.
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++
On Thu, 2023-12-14 at 15:06 +0100, Jan Beulich wrote:
> 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
>
On Thu, 2023-12-14 at 16:06 +0100, Jan Beulich wrote:
> 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
> > +
> >
On 18/12/23 08:42, Jan Beulich wrote:
On 15.12.2023 10:26, Federico Serafini wrote:
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -327,6 +327,34 @@ therefore have the same behavior of a boolean"
flight 184163 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184163/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 74daeded0cabe87d26546f07f9a3911cb60ec0e1
baseline version:
ovmf
On 18.12.2023 10:56, Oleksii wrote:
> On Thu, 2023-12-14 at 14:27 +0100, Jan Beulich wrote:
>> 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
On 18.12.2023 11:04, Oleksii wrote:
> On Thu, 2023-12-14 at 15:09 +0100, Jan Beulich wrote:
>> 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
flight 184161 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184161/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184155
On Thu, 2023-12-14 at 16:08 +0100, Jan Beulich wrote:
> 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
On 18.12.2023 11:02, Oleksii wrote:
> On Thu, 2023-12-14 at 15:06 +0100, Jan Beulich wrote:
>> 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
On Thu, 2023-12-14 at 15:09 +0100, Jan Beulich wrote:
> 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
On Thu, 2023-12-14 at 16:05 +0100, Jan Beulich wrote:
> 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__
> > +
> >
On Thu, 2023-12-14 at 14:27 +0100, Jan Beulich wrote:
> 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
>
On Thu, 2023-12-14 at 15:19 +0100, Jan Beulich wrote:
> 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
The break statement is redundant, hence it can be removed.
Signed-off-by: Nicola Vetrini
---
Changes in v2:
- Remove the outer break, instead of the inner one.
---
xen/arch/x86/platform_hypercall.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/arch/x86/platform_hypercall.c
There are no paths that can reach the last return statement
of function 'vgic_v3_its_mmio_write' in 'vcig-v3-its.c' and
'arch_memory_op' in 'arch/arm/mm.c', thus violating
MISRA C:2012 Rule 2.1:
"A project shall not contain unreachable code".
Therefore, an ASSERT_UNREACHABLE() is inserted to
The presence of an unlinked object file triggers a violation
of MISRA C Rule 2.1, which is deviated, as it's not part of
the final Xen binary.
No functional change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 5 +
1 file changed, 5 insertions(+)
The "return 0" after the swich statement in 'xen/arch/x86/mm.c'
is unreachable because all switch clauses end with returns, and
can thus be dropped.
No functional changes.
Signed-off-by: Nicola Vetrini
---
Changes in v2:
- Drop the final return instead. A stripped-down version of this switch
MISRA C:2012 Rule 2.1 states: "A project shall not contain unreachable code".
As such, this series eliminates various instances of unreachable code found in
Xen, by providing equivalent compliant constructs.
This series is loosely based on my earlier series [1], but the overall approach
has
The statements after a call to the noreturn function 'do_unexpected_trap'
can't be reached, thus violating MISRA C:2012 Rule 2.1
("A project shall not contain unreachable code.").
ASSERT_UNREACHABLE() is used to signal that the unreachable break-s are used as
a defensive coding measure to prevent
There is no path that reaches the call to 'advance_pc', thus violating MISRA C
Rule 2.1.
A call to ASSERT_UNREACHABLE() is added after the switch, despite this being
useful to detect errors only in debug builds; if that marker is ever reached,
a domain crash is triggered, as a defensive coding
Given that 'hwdom_shutdown' is a noreturn function, unreachable
breaks can be eliminated to resolve violations of Rule 2.1.
The rename s/maybe_reboot/reboot_or_halt/ is done to clarify
that the function is noreturn.
No functional change.
Signed-off-by: Nicola Vetrini
---
Changes in v2:
-
MISRA C:2012 Rule 16.3 states that an unconditional break statement
shall terminate every switch-clause.
Update ECLAIR configuration to take into account:
- continue, goto, return statements;
- functions with attribute noreturn;
- pseudo-keyword fallthrough;
- macro BUG();
- comments.
A new pre-release of our guest agent prototype written in Rust is
available, numbered 0.3.0 [1]. Identified issues and work to be done
are tracked in Gitlab issue tracker [2].
As always, feedback will be greatly appreciated!
Highlights:
### new features
* available and total guest memory are
Hi Sebastian,
On 12/15/23 6:07 PM, Sebastian Andrzej Siewior wrote:
The per-CPU variables used during bpf_prog_run_xdp() invocation and
later during xdp_do_redirect() rely on disabled BH for their protection.
Without locking in local_bh_disable() on PREEMPT_RT these data structure
require
On Thu, 2023-12-14 at 17:04 +0100, Jan Beulich wrote:
> 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 */
On 18.12.2023 11:39, Oleksii wrote:
> On Thu, 2023-12-14 at 16:55 +0100, Jan Beulich wrote:
>> 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
On Mon, 2023-12-18 at 12:28 +0100, Jan Beulich wrote:
> On 18.12.2023 11:39, Oleksii wrote:
> > On Thu, 2023-12-14 at 16:55 +0100, Jan Beulich wrote:
> > > On 24.11.2023 11:30, Oleksii Kurochko wrote:
> > > > --- a/xen/arch/riscv/include/asm/current.h
> > > > +++
On 14/12/23 17:32, Jan Beulich wrote:
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
Following on from the CMOS/RTC port aliasing change, there are some
more missing restrictions; in particular there's more port aliasing to
be aware of. But first of all introduce a command line option to allow
suppressing this probing of aliases, as was requested.
Of course an alternative to all
... in order to also deny Dom0 access through the alias ports. Without
this it is only giving the impression of denying access to PIT. Unlike
for CMOS/RTC, do detection pretty early, to avoid disturbing normal
operation later on (even if typically we won't use much of the PIT).
Like for CMOS/RTC
... in order to also deny Dom0 access through the alias ports. Without
this it is only giving the impression of denying access to both PICs.
Unlike for CMOS/RTC, do detection very early, to avoid disturbing normal
operation later on.
Like for CMOS/RTC a fundamental assumption of the probing is
Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> Delete these functions because nothing calls these functions anymore.
>
> I introduced these APIs in commit 98563fc3ec44 ("aio: add
> aio_context_acquire() and aio_context_release()") in 2014. It's with a
> sigh of relief that I delete
On 18/12/2023 3:34 pm, Joe Tretter wrote:
> Hello,
>
> I discussed the below problem with the QubesOS team on Github
> (https://github.com/QubesOS/qubes-issues/issues/4493) and they suggest
> that this seems to be a problem with Xen, and suggested that I post it
> to this e-mail address.
>
> I
On Thu, 2023-12-14 at 17:20 +0100, Jan Beulich wrote:
> 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
flight 184162 linux-linus real [real]
flight 184166 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184162/
http://logs.test-lab.xenproject.org/osstest/logs/184166/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 18.12.2023 14:46, Jan Beulich wrote:
> On 18.12.2023 13:11, Roger Pau Monné wrote:
>> Hello,
>>
>> I'm not as expert as Andrew in all the speculation stuff, but I will
>> try to provide some feedback.
>>
>> On Tue, Feb 14, 2023 at 05:10:42PM +0100, Jan Beulich wrote:
>>> In order to be able to
On 18.12.2023 14:46, Jan Beulich wrote:
> On 18.12.2023 13:11, Roger Pau Monné wrote:
>> On Tue, Feb 14, 2023 at 05:10:42PM +0100, Jan Beulich wrote:
>>> ---
>>> I have to admit that I'm not really certain about the placement of the
>>> IBPB wrt the MSR_SPEC_CTRL writes. For now I've simply used
On Mon, 2023-12-11 at 16:56 +0100, Jan Beulich wrote:
> On 07.12.2023 21:17, Andrew Cooper wrote:
> > On 07/12/2023 5:03 pm, Oleksii Kurochko wrote:
> > > ARCH_FIXED_CONFIG is required in the case of randconfig
> > > and CI for configs that aren't ready or are not
> > > supposed to be implemented
Such declaration is moved in order to provide it for Arm and PPC,
whilst not violating MISRA C:2012 Rule 8.4 in common/page_alloc.c:
"A compatible declaration shall be visible when an object or
function with external linkage is defined".
Signed-off-by: Julien Grall
Signed-off-by: Nicola Vetrini
On Mon, Dec 18, 2023 at 02:50:27PM +0100, Jan Beulich wrote:
> On 18.12.2023 14:46, Jan Beulich wrote:
> > On 18.12.2023 13:11, Roger Pau Monné wrote:
> >> Hello,
> >>
> >> I'm not as expert as Andrew in all the speculation stuff, but I will
> >> try to provide some feedback.
> >>
> >> On Tue, Feb
On Thu, 2023-12-14 at 16:55 +0100, Jan Beulich wrote:
> 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
> >
On 18.12.2023 11:49, Oleksii wrote:
> On Thu, 2023-12-14 at 17:04 +0100, Jan Beulich wrote:
>> On 24.11.2023 11:30, Oleksii Kurochko wrote:
>>> +static inline void cpu_relax(void)
>>> +{
>>> + int dummy;
>>> + /* In lieu of a halt instruction, induce a long-latency
>>> stall. */
>>> +
On 12/18/2023 12:14 AM, Peter Xu wrote:
> On Wed, Dec 13, 2023 at 10:35:33AM -0500, Steven Sistare wrote:
>> Hi Peter, all have RB's, with all i's dotted and t's crossed - steve
>
> Yes this seems to be more migration related so maybe good candidate for a
> pull from migration submodule.
>
> But
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Reviewed-by: Jan Beulich
with ...
> --- a/xen/arch/riscv/configs/tiny64_defconfig
> +++ b/xen/arch/riscv/configs/tiny64_defconfig
> @@ -24,7 +24,6 @@
> # CONFIG_COVERAGE is not set
> # CONFIG_UBSAN is not set
> #
On Thu, 2023-12-14 at 18:08 +0100, Jan Beulich wrote:
> 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
> >
On Mon, 2023-12-18 at 12:36 +0100, Jan Beulich wrote:
> On 18.12.2023 11:45, Oleksii wrote:
> > On Thu, 2023-12-14 at 16:57 +0100, Jan Beulich wrote:
> > > On 24.11.2023 11:30, Oleksii Kurochko wrote:
> > > > Signed-off-by: Oleksii Kurochko
> > >
> > > Acked-by: Jan Beulich
> > >
> > > I
On 18.12.2023 12:57, Oleksii wrote:
> On Mon, 2023-12-18 at 12:36 +0100, Jan Beulich wrote:
>> On 18.12.2023 11:45, Oleksii wrote:
>>> On Thu, 2023-12-14 at 16:57 +0100, Jan Beulich wrote:
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Acked-by:
On 14/12/23 13:36, Jan Beulich wrote:
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
As observed by Roger while reviewing a somewhat related change, there's
no need here either to open-code the (largely, i.e. once setup_max_pdx()
was called) fixed relationship between max_pdx and max_page. Further we
can avoid open-coding pfn_to_paddr() here.
Signed-off-by: Jan Beulich
---
On Tue, Feb 14, 2023 at 05:11:40PM +0100, Jan Beulich wrote:
> When the outgoing vCPU had IBPB issued and RSB overwritten upon entering
> Xen, then there's no need for a 2nd barrier during context switch.
>
> Note that SCF_entry_ibpb is always clear for the idle domain, so no
> explicit idle
On 18.12.2023 11:45, Oleksii wrote:
> On Thu, 2023-12-14 at 16:57 +0100, Jan Beulich wrote:
>> 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
>>> +++
Exclude efibind.h for all the architectures: it is used to build the
efi stub, which is a separate entry point for Xen when booted from EFI
firmware.
Remove redundant entries from out_of_scope.ecl.
Exclude common/coverage: it is code to support gcov, hence it is part
of the testing machinery.
Loading is_master from the state save record can lead to out-of-bounds
accesses via at least the two container_of() uses by vpic_domain() and
__vpic_lock(). Make sure the value is consistent with the instance being
loaded.
For ->int_output (which for whatever reason isn't a 1-bit bitfield),
In particular pit_latch_status() and speaker_ioport_read() perform
calculations which assume in-bounds values. Several of the state save
record fields can hold wider ranges, though. Refuse to load values which
cannot result from normal operation, except mode, the init state of
which (see also
Move the checking into a check hook, and add checking of the padding
fields as well.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -749,6 +749,30 @@ static int cf_check irq_load_isa(struct
return 0;
}
+static int cf_check
Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> The AioContext lock no longer has any effect. Remove it.
>
> Signed-off-by: Stefan Hajnoczi
> Reviewed-by: Eric Blake
Reviewed-by: Kevin Wolf
Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> Now that the AioContext lock no longer exists, AIO_WAIT_WHILE() and
> AIO_WAIT_WHILE_UNLOCKED() are equivalent.
>
> A future patch will get rid of AIO_WAIT_WHILE_UNLOCKED().
>
> Signed-off-by: Stefan Hajnoczi
> Reviewed-by: Eric Blake
Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> The bdrv_co_lock() and bdrv_co_unlock() functions are already no-ops.
> Remove them.
>
> Signed-off-by: Stefan Hajnoczi
Reviewed-by: Kevin Wolf
On Mon, Dec 18, 2023 at 02:46:37PM +0100, Jan Beulich wrote:
> On 18.12.2023 13:11, Roger Pau Monné wrote:
> > Hello,
> >
> > I'm not as expert as Andrew in all the speculation stuff, but I will
> > try to provide some feedback.
> >
> > On Tue, Feb 14, 2023 at 05:10:42PM +0100, Jan Beulich
On Thu, 2023-12-14 at 16:48 +0100, Jan Beulich wrote:
> 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.
>
> > ---
On Thu, 2023-12-14 at 16:57 +0100, Jan Beulich wrote:
> 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
On Mon, 2023-12-18 at 11:12 +0100, Jan Beulich wrote:
> On 18.12.2023 11:04, Oleksii wrote:
> > On Thu, 2023-12-14 at 15:09 +0100, Jan Beulich wrote:
> > > On 24.11.2023 11:30, Oleksii Kurochko wrote:
> > > > Signed-off-by: Oleksii Kurochko
> > > > ---
> > > > Changes in V2:
> > > > - add
On Tue, Feb 14, 2023 at 05:11:05PM +0100, Jan Beulich wrote:
> In order to avoid clobbering Xen's own predictions, defer the barrier as
> much as possible. Merely mark the CPU as needing a barrier issued the
> next time we're exiting to guest context.
While I understand that doing the flush in
On 18.12.2023 13:11, Roger Pau Monné wrote:
> Hello,
>
> I'm not as expert as Andrew in all the speculation stuff, but I will
> try to provide some feedback.
>
> On Tue, Feb 14, 2023 at 05:10:42PM +0100, Jan Beulich wrote:
>> In order to be able to defer the context switch IBPB to the last
>>
With the request to convert bounding to actual refusal, and then
doing so in new hooks, the two previously separate patches now need
to be in a series, with infrastructure work done first. Clearly the
checking in other load handlers could (and likely wants to be) moved
to separate check handlers
By default there's already no use for this when we run in shim mode.
Plus there may also be a need to suppress the probing in case of issues
with it. Before introducing further port alias probing, introduce a
command line option allowing to bypass it, default it to on when in shim
mode, and gate
On 14/12/23 17:36, Jan Beulich wrote:
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
On 18/12/2023 3:13 pm, Jan Beulich wrote:
> As observed by Roger while reviewing a somewhat related change, there's
> no need here either to open-code the (largely, i.e. once setup_max_pdx()
> was called) fixed relationship between max_pdx and max_page. Further we
> can avoid open-coding
Am 05.12.2023 um 19:19 hat Stefan Hajnoczi geschrieben:
> Since the removal of AioContext locking, the correctness of the code
> relies on running requests from a single AioContext at any given time.
>
> Add assertions that verify that callbacks are invoked in the correct
> AioContext.
>
>
On Mon, Dec 18, 2023 at 09:26:24AM +0100, Jan Beulich wrote:
> On 15.12.2023 15:54, Roger Pau Monné wrote:
> > On Wed, Jun 07, 2023 at 08:17:30AM +0200, Jan Beulich wrote:
> >> While frame table setup, directmap init, and boot allocator population
> >> respect all intended bounds, the logic
On 18.12.2023 11:36, Oleksii wrote:
> On Thu, 2023-12-14 at 16:48 +0100, Jan Beulich wrote:
>> On 24.11.2023 11:30, Oleksii Kurochko wrote:
>>> +#define SLOTN_ENTRY_SIZE SLOTN(1)
>>> +
>>> #define XEN_VIRT_START 0xC000 /* (_AC(-1, UL) + 1 -
>>> GB(1)) */
>>> +
>>> +#define
Hi all,
Merry Christmas!
Just a quick update from myself.
Whilst I can’t speak for everyone in the community, I know we have valuable
members who are committed to making the Xen Project successful. We are a
strong and passionate community made up of individuals who consistently
seek improvement
Hello,
I'm not as expert as Andrew in all the speculation stuff, but I will
try to provide some feedback.
On Tue, Feb 14, 2023 at 05:10:42PM +0100, Jan Beulich wrote:
> In order to be able to defer the context switch IBPB to the last
> possible point, add logic to the exit-to-guest paths to
On 18.12.2023 13:39, Roger Pau Monné wrote:
> On Tue, Feb 14, 2023 at 05:11:05PM +0100, Jan Beulich wrote:
>> In order to avoid clobbering Xen's own predictions, defer the barrier as
>> much as possible. Merely mark the CPU as needing a barrier issued the
>> next time we're exiting to guest
Pipeline #177680 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging-4.17 (
https://gitlab.com/xen-project/xen/-/commits/staging-4.17 )
Commit: 949a4aad (
https://gitlab.com/xen-project/xen/-/commit/949a4aad417621638231e4cf9f1b35e8e0328463
)
Commit Message:
..., at least as reasonably feasible without making a check hook
mandatory (in particular strict vs relaxed/zero-extend length checking
can't be done early this way).
Note that only one of the two uses of "real" hvm_load() is accompanied
with a "checking" one. The other directly consumes
Register NULL uniformly as a first step.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v2: New.
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -374,7 +374,7 @@ static int cf_check vmce_load_vcpu_ctxt(
return err ?: vmce_restore_vcpu(v, );
}
On 12.12.2023 02:48, Stefano Stabellini wrote:
> On Mon, 11 Dec 2023, Nicola Vetrini wrote:
>> No functional change.
>>
>> Signed-off-by: Nicola Vetrini
>
> Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
Hi Jens,
> On 13 Dec 2023, at 11:31, Jens Wiklander wrote:
>
> Until now has FFA_PARTITION_INFO_GET always returned zero in w3, but
> FF-A v1.1 requires FFA_PARTITION_INFO_GET to return the size of each
> partition information descriptor returned if
> FFA_PARTITION_INFO_GET_COUNT_FLAG isn't
On 18.12.2023 12:13, Roger Pau Monné wrote:
> On Mon, Dec 18, 2023 at 09:26:24AM +0100, Jan Beulich wrote:
>> On 15.12.2023 15:54, Roger Pau Monné wrote:
>>> On Wed, Jun 07, 2023 at 08:17:30AM +0200, Jan Beulich wrote:
While frame table setup, directmap init, and boot allocator population
On 18.12.2023 16:19, Roger Pau Monné wrote:
> On Tue, Feb 14, 2023 at 05:11:40PM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -2005,17 +2005,26 @@ void context_switch(struct vcpu *prev, s
>> }
>> else
>> {
>> +unsigned int
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/mm.c
> +++ b/xen/arch/riscv/mm.c
> @@ -1,19 +1,23 @@
> /* SPDX-License-Identifier: GPL-2.0-only */
>
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
>
> #include
>
flight 184165 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184165/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184109
On Mon, 18 Dec 2023, Federico Serafini wrote:
> Deviate typedef names that are delberately defined multiple times.
>
> Update docs/misra/deviations.rst accordingly.
>
> Tag Rule 5.6 as clean.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> The "return 0" after the swich statement in 'xen/arch/x86/mm.c'
> is unreachable because all switch clauses end with returns, and
> can thus be dropped.
>
> No functional changes.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> Such declaration is moved in order to provide it for Arm and PPC,
> whilst not violating MISRA C:2012 Rule 8.4 in common/page_alloc.c:
> "A compatible declaration shall be visible when an object or
> function with external linkage is defined".
>
>
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> There are no paths that can reach the last return statement
> of function 'vgic_v3_its_mmio_write' in 'vcig-v3-its.c' and
> 'arch_memory_op' in 'arch/arm/mm.c', thus violating
> MISRA C:2012 Rule 2.1:
> "A project shall not contain unreachable code".
>
On Mon, 18 Dec 2023, Federico Serafini wrote:
> MISRA C:2012 Rule 16.3 states that an unconditional break statement
> shall terminate every switch-clause.
>
> Update ECLAIR configuration to take into account:
> - continue, goto, return statements;
> - functions with attribute noreturn;
> -
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> Given that 'hwdom_shutdown' is a noreturn function, unreachable
> breaks can be eliminated to resolve violations of Rule 2.1.
>
> The rename s/maybe_reboot/reboot_or_halt/ is done to clarify
> that the function is noreturn.
>
> No functional change.
>
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> There is no path that reaches the call to 'advance_pc', thus violating MISRA C
> Rule 2.1.
> A call to ASSERT_UNREACHABLE() is added after the switch, despite this being
> useful to detect errors only in debug builds; if that marker is ever reached,
> a
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> The presence of an unlinked object file triggers a violation
> of MISRA C Rule 2.1, which is deviated, as it's not part of
> the final Xen binary.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Acked-by: Stefano Stabellini
> ---
>
On 18/12/2023 11:36 pm, Joe Tretter wrote:
> Hi Andrew,
>
> I have tried it with your suggested command line, and it "feels" like
> it makes the issue occur less often (but one never knows with sparse
> intermittent issues).
> The first time I ran my test, it took 23 minutes before the error
>
On Mon, 18 Dec 2023, Jan Beulich wrote:
> On 15.12.2023 22:02, Stefano Stabellini wrote:
> > On Fri, 15 Dec 2023, Jan Beulich wrote:
> >> 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:
> > ---
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> The statements after a call to the noreturn function 'do_unexpected_trap'
> can't be reached, thus violating MISRA C:2012 Rule 2.1
> ("A project shall not contain unreachable code.").
> ASSERT_UNREACHABLE() is used to signal that the unreachable break-s
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> The break statement is redundant, hence it can be removed.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Mon, 18 Dec 2023, Federico Serafini wrote:
> Exclude efibind.h for all the architectures: it is used to build the
> efi stub, which is a separate entry point for Xen when booted from EFI
> firmware.
> Remove redundant entries from out_of_scope.ecl.
>
> Exclude common/coverage: it is code to
On Mon, 18 Dec 2023, Stefano Stabellini wrote:
> On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> > The presence of an unlinked object file triggers a violation
> > of MISRA C Rule 2.1, which is deviated, as it's not part of
> > the final Xen binary.
> >
> > No functional change.
> >
> >
1 - 100 of 136 matches
Mail list logo
