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"
-config=MC3R1.R14.4,etypes+={del
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 allo
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 n
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.
U
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 3ce5f2d445e51efe2aeba
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 ++
automation/eclair_analysi
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
> in
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 explic
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
>
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
test-amd64-amd64-xl-qemut-win7-amd64
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 go
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 loo
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 paddr_bit
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__
> > +
> > +#inc
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.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 __ASM_RISCV_G
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 vcpu_mark_events_pending(str
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 !
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 has
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 change
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 i
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 meas
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:
- rename
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
b/xen/arch/x
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 remov
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(+)
dif
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.
>
> > --- a/xen/arch/riscv/include/asm
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 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 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 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
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 passing
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 FRAME
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 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
> > +#includ
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
>>> +++ b/xen/arch/r
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. */
>>> + __asm__
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 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
> > > > +++ b/xen/arch/riscv/include/asm/curren
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.
Exc
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 wonder
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
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: J
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 issue
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 the
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
>> pos
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 d
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):
test-armhf-
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 context
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 "o
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
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 f
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: up
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 to
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 ( &n[1] >= __note_gnu_build_id_end )
return;
-sz = (void *)__note_gnu_build_id_en
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 set.
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 as
..., 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 hvm_save(
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, &ctxt);
}
-H
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 below
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),
beside
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 irq_check_l
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
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 o
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 RT
... 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 tha
... 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 a
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 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 ACPI_COMPA
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
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
--- a/xen
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 domai
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 pfn_to_pad
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
> #
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.
>
> Signed
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
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
R
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 thes
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 wrote:
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 have
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 18.12.2023 16:40, Roger Pau Monné wrote:
> 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,
On 18.12.2023 16:43, Roger Pau Monné wrote:
> 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 t
On 11/12/2023 3:56 pm, 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 for specific archite
On 18.12.2023 16:19, Roger Pau Monné wrote:
> 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
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 feat
On 18.12.2023 17:07, Andrew Cooper wrote:
> On 11/12/2023 3:56 pm, 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
>>>
> >>> On 05.12.2023 21:31, Sébastien Chaumat wrote:
> > [2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt
>
> Is it expected that IRQ7 goes from fasteoi (kernel 6.6.4 ) to
> ioapic-edge and IRQ9 to ioapic-level ?
>
> IR-IO-APIC7-fasteoi pinct
Pipeline #343260 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 0cc74376 (
https://gitlab.com/xen-project/xen/-/commit/0cc74376d6823e0883f89556be2a267f2240a558
)
Commit Message: x86/hvm: addr
On 18.12.2023 17:21, Sébastien Chaumat wrote:
> On 05.12.2023 21:31, Sébastien Chaumat wrote:
>>> This issue seems that IRQ 7 (the GPIO controller) is natively fasteoi
>>> (so level type) while in xen it is mapped to oapic-edge instead of
>>> oapic-level
>>> as the SSDT indicates :
>>>
>>> D
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
> #in
On 14.12.2023 22:29, Stefano Stabellini wrote:
> On Thu, 14 Dec 2023, Nicola Vetrini wrote:
>> No functional change.
>>
>> Signed-off-by: Nicola Vetrini
>
> Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
Yet it would have been really nice if style had been tidied of the lines
which are
On 14.12.2023 22:30, Stefano Stabellini wrote:
> 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
Acked-by: Jan Beulich
Le lun. 18 déc. 2023, 17:44, Jan Beulich a écrit :
> On 18.12.2023 17:21, Sébastien Chaumat wrote:
> > On 05.12.2023 21:31, Sébastien Chaumat wrote:
> >>> This issue seems that IRQ 7 (the GPIO controller) is natively fasteoi
> >>> (so level type) while in xen it is mapped to oapic-edge inst
On 14.12.2023 12:44, Nicola Vetrini wrote:
> --- a/xen/include/acpi/acmacros.h
> +++ b/xen/include/acpi/acmacros.h
> @@ -111,7 +111,7 @@
>
> #define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void,(void *)
> NULL,(acpi_native_uint) i)
> #define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF
On Tue, Feb 14, 2023 at 05:12:08PM +0100, Jan Beulich wrote:
> Since both kernel and user mode run in ring 3, they run in the same
> "predictor mode".
That only true when IBRS is enabled, otherwise all CPU modes share the
same predictor mode?
> While the kernel could take care of this itself, doi
On Mon, Dec 18, 2023 at 02:58:01PM +0100, Jan Beulich wrote:
> 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 nee
On 2023-12-18 18:05, Jan Beulich wrote:
On 14.12.2023 12:44, Nicola Vetrini wrote:
--- a/xen/include/acpi/acmacros.h
+++ b/xen/include/acpi/acmacros.h
@@ -111,7 +111,7 @@
#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void,(void *)
NULL,(acpi_native_uint) i)
#define ACPI_TO_INTEGER(p)
1 - 100 of 136 matches
Mail list logo
