As function xsm_sysctl() is solely invoked in sysctl.c, we need to
wrap around it with CONFIG_SYSCTL
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
xen/include/xsm/xsm.h | 4
xen/xsm/dummy.c | 2 ++
xen/xsm/flask/hooks.c | 4
3 files changed, 10 insertions(+)
di
From: Stefano Stabellini
We introduce a new Kconfig CONFIG_SYSCTL, which shall only be disabled
on some dom0less systems or PV shim on x86, to reduce Xen footprint.
Making SYSCTL without prompt is transient and it will be adjusted in the final
patch. And the consequence of introducing "CONFIG_SY
Users could only access trace buffers via hypercall XEN_SYSCTL_tbuf_op,
so we shall make CONFIG_TRACEBUFFER depend on CONFIG_SYSCTL
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
xen/common/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/common/Kconfig b/xen/comm
The following functions are only to deal with XEN_SYSCTL_page_offline_op,
then shall be wrapped:
- xsm_page_offline()
- online_page()
- query_page_offline()
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v1 -> v2:
- add transient #ifdef in sysctl.c for correct compilation
- no ne
On 04.07.2025 12:10, Sergiy Kibrik wrote:
> 01.07.25 13:42, Jan Beulich:
>> On 30.06.2025 10:55, Sergiy Kibrik wrote:
>>> @@ -54,4 +54,7 @@ $(obj)/policy.bin: FORCE
>>> FLASK_BUILD_DIR=$(FLASK_BUILD_DIR) POLICY_FILENAME=$(POLICY_SRC)
>>> cmp -s $(POLICY_SRC) $@ || cp $(POLICY_SRC) $
On 04.07.2025 10:56, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Friday, July 4, 2025 4:33 PM
>> To: Penny, Zheng ; Andryuk, Jason
>>
>> Cc: Huang, Ray ; Anthony PERARD
>> ; Juergen Gross ; Andrew
>> Cooper ; Orzel, Michal ;
>> Julien Grall ; Roge
From: Stefano Stabellini
Wrap sysctl hypercall def and sysctl.o with CONFIG_SYSCTL, and since
PV_SHIM_EXCLUSIVE needs sorting in the future, we move them out of
PV_SHIM_EXCLUSIVE condition at the same time.
We need to make SYSCTL with prompt back, add help info and set default
value as y. We sha
Remove all "depends on !PV_SHIM_EXCLUSIVE" (also the functionally
equivalent "if !...") in Kconfig file, since negative dependancy will badly
affect allyesconfig. Although "if !PV_SHIM_EXCLUSIVE" for CONFIG_VGA is not
truly a dependency, setting PV_SHIM_EXCLUSIVE y still makes it unconfigurable.
So
> On 2 Jul 2025, at 20.53, Philippe Mathieu-Daudé wrote:
>
> In order to dispatch over AccelOpsClass::get_virtual_clock(),
> we need it always defined, not calling a hidden handler under
> the hood. Make AccelOpsClass::get_virtual_clock() mandatory.
> Register the default cpus_kick_thread() for
> On 2 Jul 2025, at 20.53, Philippe Mathieu-Daudé wrote:
>
> In order to dispatch over AccelOpsClass::get_elapsed_ticks(),
> we need it always defined, not calling a hidden handler under
> the hood. Make AccelOpsClass::get_elapsed_ticks() mandatory.
> Register the default cpus_kick_thread() for
01.07.25 13:42, Jan Beulich:
On 30.06.2025 10:55, Sergiy Kibrik wrote:
Currently Xen lacks a defined largest number of security IDs it can potentially
use. The number of SIDs are naturally limited by number of security contexts
provided by a given security policy, i.e. how many combination of us
On 03/07/2025 2:30 pm, Jan Beulich wrote:
> On 03.07.2025 14:37, Andrew Cooper wrote:
>> On 03/07/2025 10:24 am, Jan Beulich wrote:
>>> On 02.07.2025 16:41, Andrew Cooper wrote:
With the recent simplifications, it becomes obvious that smp_mb() isn't the
right barrier; all we need is a com
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Friday, July 4, 2025 4:33 PM
> To: Penny, Zheng ; Andryuk, Jason
>
> Cc: Huang, Ray ; Anthony PERARD
> ; Juergen Gross ; Andrew
> Cooper ; Orzel, Michal ;
> Julien Grall ; Roger Pau Monné ; Stefano
> Stabellini ; xen-devel@lists.x
The current look and feel of setup_mm() leaves a lot to be desired. The
scope of variables is not the best, many variables are not really needed
while some others are set but not used. The first iteration of membanks
is split from the loop for no reason. Tidy up this function for better
readability
On 04.07.2025 11:29, Penny Zheng wrote:
> It can be beneficial for some dom0less systems to further reduce Xen footprint
> via disabling some hypercalls handling code, which may not to be used &
> required in such systems. Each hypercall has a separate option to keep
> configuration flexible.
>
>
Function arch_do_sysctl is to perform arch-specific sysctl op.
Some functions, like psr_get_info() for x86, DTB overlay support for arm,
are solely available through sysctl op, then they all shall be wrapped
with CONFIG_SYSCTL
Also, remove all #ifdef CONFIG_SYSCTL-s in arch-specific sysctl.c, as
w
Function sched_adjust_global is designed for XEN_SYSCTL_scheduler_op, so
itself and its calling flow, like .adjust_global, shall all be wrapped.
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
Acked-by: Stewart Hildebrand #a653
---
v1 -> v2:
- no need to wrap declarations
- add trans
LIVEPATCH mechanism relies on LIVEPATCH_SYSCTL hypercall, so CONFIG_LIVEPATCH
shall depend on CONFIG_SYSCTL
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v1 -> v2:
- commit message refactor
---
xen/common/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The following functions are only used to deal with XEN_SYSCTL_physinfo,
then they shall be wrapped:
- arch_do_physinfo()
- get_outstanding_claims()
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
---
v1 -> v2:
- no need to wrap declaration
- add transient #ifdef
Users rely on SYSCTL_coverage_op hypercall to interact with the coverage data,
that is, according operations shall be wrapped around with CONFIG_SYSCTL.
Right now, it is compiled under CONFIG_COVERAGE, so we shall make
CONFIG_COVERAGE depend on CONFIG_SYSCTL.
Signed-off-by: Penny Zheng
Reviewed-b
We introduce a new Kconfig CONFIG_PM_STATS for wrapping all operations
regarding performance management statistics.
The major codes reside in xen/drivers/acpi/pmstat.c, including the
pm-statistic-related sysctl op: do_get_pm_info().
CONFIG_PM_STATS also shall depend on CONFIG_SYSCTL
We shall also
We move the following functions into a new file drivers/acpi/pm-op.c, as
they are all more fitting in performance controling and only called by
do_pm_op():
- get_cpufreq_para()
- set_cpufreq_para()
- set_cpufreq_gov()
- set_cpufreq_cppc()
- cpufreq_driver_getavg()
- cpufreq_update_turbo()
-
The following function is only to serve spinlock profiling via
XEN_SYSCTL_lockprof_op, so it shall be wrapped:
- spinlock_profile_control()
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v2 -> v3:
- add the blank line
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
x
The following functions is to deal with XEN_SYSCTL_readconsole sub-op, and
shall be wrapped:
- xsm_readconsole()
- read_console_ring()
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v2 -> v3:
- move #endif up ahead of the blank line
---
v3 -> v4:
- remove transient "#ifdef CONFIG
The following function shall be wrapped:
- scheduler_id()
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
xen/common/sched/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/common/sched/core.c b/xen/common/sch
It can be beneficial for some dom0less systems to further reduce Xen footprint
via disabling some hypercalls handling code, which may not to be used &
required in such systems. Each hypercall has a separate option to keep
configuration flexible.
Options to disable hypercalls:
- sysctl
- domctl
- h
Function cpupool_do_sysctl is designed for doing cpupool related sysctl
operations, and shall be wrapped.
The following static functions are only called by cpupool_do_sysctl(), then
shall be wrapped too:
- cpupool_get_next_by_id
- cpupool_destroy
- cpupool_unassign_cpu_helper
- cpupool_unassign_cp
perfc_control() and perfc_copy_info() are responsible for providing control
of perf counters via XEN_SYSCTL_perfc_op in DOM0, so they both shall
be wrapped.
Signed-off-by: Penny Zheng
Reviewed-by: Stefano Stabellini
---
v2 -> v3:
- add the blank line
---
v3 -> v4:
- remove transient "#ifdef CONF
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Friday, July 4, 2025 5:49 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Anthony PERARD ;
> Orzel, Michal ; Julien Grall ; Roger Pau
> Monné ; Stefano Stabellini ;
> Daniel
> P. Smith ; Dario Faggioli ;
> Juergen Gros
On Thu, Jul 03, 2025 at 07:32:36PM +0200, Philippe Mathieu-Daudé wrote:
> Date: Thu, 3 Jul 2025 19:32:36 +0200
> From: Philippe Mathieu-Daudé
> Subject: [PATCH v6 30/39] accel: Propagate AccelState to
> AccelClass::init_machine()
> X-Mailer: git-send-email 2.49.0
>
> In order to avoid init_mach
> On 2 Jul 2025, at 20.53, Philippe Mathieu-Daudé wrote:
>
> In order to dispatch over AccelOpsClass::handle_interrupt(),
> we need it always defined, not calling a hidden handler under
> the hood. Make AccelOpsClass::handle_interrupt() mandatory.
> Expose generic_handle_interrupt() prototype a
On 7/3/25 11:32, Philippe Mathieu-Daudé wrote:
Only accelerator implementations (and the common accelator
code) need to know about AccelClass internals. Move the
definition out but forward declare AccelState and AccelClass.
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS
On 7/3/25 11:32, Philippe Mathieu-Daudé wrote:
Unfortunately "system/accel-ops.h" handlers are not only
system-specific. For example, the cpu_reset_hold() hook
is part of the vCPU creation, after it is realized.
Mechanical rename to drop 'system' using:
$ sed -i -e s_system/accel-ops.h_accel
On 6/30/25 4:27 PM, Jan Beulich wrote:
--- a/xen/arch/riscv/include/asm/smp.h
+++ b/xen/arch/riscv/include/asm/smp.h
@@ -3,6 +3,7 @@
#define ASM__RISCV__SMP_H
#include
+#include
#include
#include
@@ -18,6 +19,18 @@ static inline unsigned long cpuid_to_hartid(unsigned long
cp
On 04/07/2025 9:25 am, Jan Beulich wrote:
> On 04.07.2025 09:55, Roger Pau Monné wrote:
>> On Fri, Jul 04, 2025 at 09:23:29AM +0200, Jan Beulich wrote:
>>> On 03.07.2025 18:21, Roger Pau Monné wrote:
On Wed, Jul 02, 2025 at 03:41:18PM +0100, Andrew Cooper wrote:
> --- a/xen/include/xen/sof
On 04/07/2025 8:24 am, Roger Pau Monné wrote:
> On Thu, Jul 03, 2025 at 06:48:23PM +0100, Andrew Cooper wrote:
>> On 03/07/2025 5:36 pm, Roger Pau Monné wrote:
>>> On Wed, Jul 02, 2025 at 03:41:19PM +0100, Andrew Cooper wrote:
In order elide IPIs, we must be able to identify whether a target C
On 04/07/2025 8:52 am, Roger Pau Monné wrote:
> On Wed, Jul 02, 2025 at 03:41:19PM +0100, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/include/asm/softirq.h
>> b/xen/arch/x86/include/asm/softirq.h
>> index e4b194f069fb..069e5716a68d 100644
>> --- a/xen/arch/x86/include/asm/softirq.h
>> +++ b/
cpuidle_wakeup_mwait() is a TOCTOU race. The cpumask_and() sampling
cpuidle_mwait_flags can take a arbitrary period of time, and there's no
guarantee that the target CPUs are still in MWAIT when writing into
mwait_wakeup(cpu).
The consequence of the race is that we'll fail to IPI certain targets.
In order elide IPIs, we must be able to identify whether a target CPU is in
MWAIT at the point it is woken up. i.e. the store to wake it up must also
identify the state.
Create a new in_mwait variable beside __softirq_pending, so we can use a
CMPXCHG to set the softirq while also observing the st
The check of this_softirq_pending must be performed with irqs disabled, but
this property was broken by an attempt to optimise entry/exit latency.
Commit c227233ad64c in Linux (which we copied into Xen) was fixed up by
edc8fc01f608 in Linux, which we have so far missed.
Going to sleep without wak
The two main bugs were identified in Linux first, and I've modelled Xen's fix
similarly.
Patches 1-4 want committing together. They do bisect and operate correctly,
but the range takes out an optimisation in order to reimplement it correctly.
https://gitlab.com/xen-project/hardware/xen-staging/-
With the recent simplifications, it becomes obvious that smp_mb() isn't the
right barrier. Strictly speaking, MONITOR is ordered as a load, but smp_rmb()
isn't correct either, as this only pertains to local ordering. All we need is
a compiler barrier().
Merge the barier() into the monitor() itse
x86 is the only architecture wanting an optimisation here, but the
test_and_set_bit() is a store into the monitored line (i.e. will wake up the
target) and, prior to the removal of the broken IPI-elision algorithm, was
racy, causing unnecessary IPIs to be sent.
To do this in a race-free way, the s
We're going to want alternative-patch based on it.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Anthony PERARD
CC: Michal Orzel
CC: Julien Grall
CC: Stefano Stabellini
---
xen/arch/x86/acpi/cpu_idle.c | 6 --
xen/arch/x86/cpu
From: Juergen Gross
[ upstream commit 41925b105e345ebc84cedb64f59d20cb14a62613 ]
xen_remap() is used to establish mappings for frames not under direct
control of the kernel: for Xenstore and console ring pages, and for
grant pages of non-PV guests.
Today xen_remap() is defined to use ioremap()
On Wed, Jul 2, 2025 at 4:11 PM Jan Beulich wrote:
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -619,6 +619,8 @@ struct domain
> > unsigned int guest_request_sync : 1;
> > } monitor;
> >
> > +unsigned int nr_altp2m;/* Number of altp2m tab
Pipeline:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/1907188989
On 7/4/25 23:39, Dmytro Prokopchuk1 wrote:
> This patch series fully eliminates MISRA C Rule 5.5
> violations for ARM64.
>
> The previous thread is here:
> https://lore.kernel.org/xen-devel/48c7830931a98b2bf70ef1
On Wed, Jul 2, 2025 at 8:47 AM Jan Beulich wrote:
>
> On 02.07.2025 01:45, Petr Beneš wrote:
> > From: Petr Beneš
> >
> > Resubmitting patch from Anton Belousov and addressing review comments
> > from Jan:
> > https://old-list-archives.xen.org/archives/html/xen-devel/2022-01/msg00725.html
>
> In
On Fri, Jul 04, 2025 at 05:34:07PM +0100, Andrew Cooper wrote:
> We're going to want alternative-patch based on it.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Roger Pau Monné
Thanks, Roger.
On Fri, Jul 04, 2025 at 05:34:06PM +0100, Andrew Cooper wrote:
> With the recent simplifications, it becomes obvious that smp_mb() isn't the
> right barrier. Strictly speaking, MONITOR is ordered as a load, but smp_rmb()
> isn't correct either, as this only pertains to local ordering. All we need
On Wed, Jul 2, 2025 at 9:15 AM Jan Beulich wrote:
>
> On 02.07.2025 01:45, Petr Beneš wrote:
> > From: Petr Beneš
>
> This isn't in line with the first S-o-b, nor with the fact that in the cover
> letter you say this was previously submitted (and hence authored?) by Anton.
Can you please point m
Add a new function to emulate extended capability list for dom0,
and call it in init_header(). So that it will be easy to hide a
extended capability whose initialization fails.
As for the extended capability list of domU, just move the logic
into above function and keep hiding it for domU.
Signed
When vpci fails to initialize a legacy capability of device, it just
returns an error and vPCI gets disabled for the whole device. That
most likely renders the device unusable, plus possibly causing issues
to Xen itself if guest attempts to program the native MSI or MSI-X
capabilities if present.
When init_msi() fails, current logic return fail and free MSI-related
resources in vpci_deassign_device(). But the previous new changes will
hide MSI capability and return success, it can't reach
vpci_deassign_device() to remove resources if hiding success, so those
resources must be removed in cle
When vpci fails to initialize a extended capability of device, it
just returns an error and vPCI gets disabled for the whole device.
So, add function to hide extended capability when initialization
fails. And remove the failed extended capability handler from vpci
extended capability list.
Signed
When init_rebar() fails, current logic return fail and free Rebar-related
resources in vpci_deassign_device(). But the previous new changes will
hide Rebar capability and return success, it can't reach
vpci_deassign_device() to remove resources if hiding success, so those
resources must be removed
Hi,
This series is to
emulate extended capability list for dom0, including patch #1.
hide legacy and extended capability when its initialization fails, including
patch #2, #3, #4.
remove all related registers and other resources when initializing capability
fails, including patch #5, #6, #7, #8.
Refactor REGISTER_VPCI_INIT to contain more capability specific
information, this will benefit further follow-on changes to hide
capability when initialization fails.
What's more, change the definition of init_header() since it is
not a capability and it is needed for all devices' PCI config space
When init_msix() fails, current logic return fail and free MSIX-related
resources in vpci_deassign_device(). But the previous new changes will
hide MSIX capability and return success, it can't reach
vpci_deassign_device() to remove resources if hiding success, so those
resources must be removed in
vpci_remove_register() only supports removing a register in a time,
but the follow-on changes need to remove all registers within a range.
So, refactor it to support removing all registers in a given region.
And it is no issue to remove a non exist register, so remove the
__must_check prefix.
Sig
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, June 17, 2025 6:08 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Anthony PERARD
> ; Juergen Gross ; Andrew
> Cooper ; Orzel, Michal ;
> Julien Grall ; Roger Pau Monné ; Stefano
> Stabellini ; xen-devel@lists.xenproject.org
> S
On 04.07.2025 09:23, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Friday, July 4, 2025 2:21 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Roger Pau Monné ; xen-
>> de...@lists.xenproject.org
>> Subject: Re: [PATCH v5 10/18] xen/cpuf
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, June 17, 2025 12:22 AM
> To: Penny, Zheng
> Cc: Huang, Ray ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v5 12/18] xen/cpufreq: get performance policy from
> governor
> set via xenpm
>
> On 27.05.2025 10:48, Pen
On Wed, Jul 02, 2025 at 03:41:19PM +0100, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/include/asm/softirq.h
> b/xen/arch/x86/include/asm/softirq.h
> index e4b194f069fb..069e5716a68d 100644
> --- a/xen/arch/x86/include/asm/softirq.h
> +++ b/xen/arch/x86/include/asm/softirq.h
> @@ -1,6 +1,8 @@
Two small patches laying a base for future PDX changes. See discussion here:
https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2507031103360.605088@ubuntu-linux-20-04-desktop/T/#m157f07f957bdad3d807ff53d05e75688a8ae6837
Michal Orzel (2):
xen/arm64: Panic if direct map is too small
xen/arm:
Harden the code by panicing if direct map is too small for current memory
layout taking into account possible PDX compression. Otherwise the assert
is observed:
Assertion '(mfn_to_pdx(maddr_to_mfn(ma)) - directmap_base_pdx) <
(DIRECTMAP_SIZE >> PAGE_SHIFT)' failed at ./arch/arm/include/asm/mmu/mm.
When CONFIG_PDX_COMPRESSION=n, pdx_init_mask(), pdx_region_mask() and
pfn_pdx_hole_setup() are just stubs doing nothing. It does not make
sense to keep the two loops iterating over all the memory banks.
Signed-off-by: Michal Orzel
---
xen/arch/arm/setup.c | 4 +++-
1 file changed, 3 insertions(+
On Fri, Jul 04, 2025 at 09:23:29AM +0200, Jan Beulich wrote:
> On 03.07.2025 18:21, Roger Pau Monné wrote:
> > On Wed, Jul 02, 2025 at 03:41:18PM +0100, Andrew Cooper wrote:
> >> --- a/xen/include/xen/softirq.h
> >> +++ b/xen/include/xen/softirq.h
> >> @@ -23,6 +23,22 @@ enum {
> >>
> >> #define
On 03.07.2025 18:21, Roger Pau Monné wrote:
> On Wed, Jul 02, 2025 at 03:41:18PM +0100, Andrew Cooper wrote:
>> --- a/xen/include/xen/softirq.h
>> +++ b/xen/include/xen/softirq.h
>> @@ -23,6 +23,22 @@ enum {
>>
>> #define NR_SOFTIRQS (NR_COMMON_SOFTIRQS + NR_ARCH_SOFTIRQS)
>>
>> +/*
>> + * Ens
On Thu, Jul 03, 2025 at 06:48:23PM +0100, Andrew Cooper wrote:
> On 03/07/2025 5:36 pm, Roger Pau Monné wrote:
> > On Wed, Jul 02, 2025 at 03:41:19PM +0100, Andrew Cooper wrote:
> >> In order elide IPIs, we must be able to identify whether a target CPU is in
> >> MWAIT at the point it is woken up.
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Friday, July 4, 2025 2:21 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Roger Pau Monné ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v5 10/18] xen/cpufreq: introduce a new amd cppc driver for
> cpufreq sc
On Thu, Jul 03, 2025 at 07:32:43PM +0200, Philippe Mathieu-Daudé wrote:
> Date: Thu, 3 Jul 2025 19:32:43 +0200
> From: Philippe Mathieu-Daudé
> Subject: [PATCH v6 37/39] accel: Rename 'system/accel-ops.h' ->
> 'accel/accel-cpu-ops.h'
> X-Mailer: git-send-email 2.49.0
>
> Unfortunately "system/a
On 04.07.2025 09:55, Roger Pau Monné wrote:
> On Fri, Jul 04, 2025 at 09:23:29AM +0200, Jan Beulich wrote:
>> On 03.07.2025 18:21, Roger Pau Monné wrote:
>>> On Wed, Jul 02, 2025 at 03:41:18PM +0100, Andrew Cooper wrote:
--- a/xen/include/xen/softirq.h
+++ b/xen/include/xen/softirq.h
On 04.07.2025 09:51, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, June 17, 2025 12:22 AM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v5 12/18] xen/cpufreq: get performance policy from
>> g
On 4/7/25 08:38, Xiaoyao Li wrote:
On 7/4/2025 1:32 AM, Philippe Mathieu-Daudé wrote:
In order to dispatch over AccelOpsClass::handle_interrupt(),
we need it always defined,
It seems I can only understand it until I see the code to really require
it to be mandatory.
See
https://lore.kerne
On 04.07.2025 10:13, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, June 17, 2025 6:08 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Anthony PERARD
>> ; Juergen Gross ; Andrew
>> Cooper ; Orzel, Michal ;
>> Julien Grall ; Roger Pau Monné ;
>>
On 04.07.2025 10:32, Jan Beulich wrote:
> On 04.07.2025 10:13, Penny, Zheng wrote:
>>> -Original Message-
>>> From: Jan Beulich
>>> Sent: Tuesday, June 17, 2025 6:08 PM
>>>
>>> On 27.05.2025 10:48, Penny Zheng wrote:
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -69,6
On Thu, Jul 03, 2025 at 07:32:44PM +0200, Philippe Mathieu-Daudé wrote:
> Date: Thu, 3 Jul 2025 19:32:44 +0200
> From: Philippe Mathieu-Daudé
> Subject: [PATCH v6 38/39] accel: Extract AccelClass definition to
> 'accel/accel-ops.h'
> X-Mailer: git-send-email 2.49.0
>
> Only accelerator implemen
On Fri, Jul 04, 2025 at 05:34:09PM +0100, Andrew Cooper wrote:
> In order elide IPIs, we must be able to identify whether a target CPU is in
> MWAIT at the point it is woken up. i.e. the store to wake it up must also
> identify the state.
>
> Create a new in_mwait variable beside __softirq_pendin
Address a violation of MISRA C:2012 Rule 5.5:
"Identifiers shall be distinct from macro names".
Reports for service MC3A2.R5.5:
xen/include/xen/bitops.h: non-compliant function '__test_and_set_bit(int,
volatile void*)'
xen/include/xen/bitops.h: non-compliant macro '__test_and_set_bit'
xen/include
Address a violation of MISRA C:2012 Rule 5.5:
"Identifiers shall be distinct from macro names".
Reports for service MC3A2.R5.5:
xen/include/xen/fdt-domain-build.h: non-compliant parameter 'copy_to_guest'
xen/include/xen/guest_access.h: non-compliant macro 'copy_to_guest'
Rename 'copy_to_guest' fu
Address a violation of MISRA C:2012 Rule 5.5:
"Identifiers shall be distinct from macro names".
Reports for service MC3A2.R5.5:
xen/include/xen/iommu.h: non-compliant struct 'page_list_head'
xen/include/xen/mm.h: non-compliant macro 'page_list_head'
xen/drivers/passthrough/iommu.c: non-compliant m
Address a violation of MISRA C:2012 Rule 5.5:
"Identifiers shall be distinct from macro names".
Reports for service MC3A2.R5.5:
xen/include/xen/irq.h: non-compliant function `pirq_cleanup_check(struct pirq*,
struct domain*)'
xen/include/xen/irq.h: non-compliant macro `pirq_cleanup_check'
The pri
Address a violation of MISRA C:2012 Rule 5.5:
"Identifiers shall be distinct from macro names".
Reports for service MC3A2.R5.5:
xen/common/grant_table.c: non-compliant macro 'update_gnttab_par'
xen/common/grant_table.c: non-compliant macro 'parse_gnttab_limit'
The macros above are intended to dis
This patch series fully eliminates MISRA C Rule 5.5
violations for ARM64.
The previous thread is here:
https://lore.kernel.org/xen-devel/48c7830931a98b2bf70ef1509f309b262b9e5792.1745427770.git.victorm.l...@amd.com/
where that violation was proposed to be deviated.
Dmytro Prokopchuk (5):
gnttab:
On 7/1/25 3:49 PM, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
This patch introduces p2m_set_entry() and its core helper __p2m_set_entry() for
RISC-V, based loosely on the Arm implementation, with several RISC-V-specific
modifications.
Key differences include:
- TLB Flushin
86 matches
Mail list logo
