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.
But anyway, the change itself is correct.
Reviewed-by: Xia
On 04.07.2025 05:40, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Wednesday, July 2, 2025 6:48 PM
>>
>> On 02.07.2025 11:49, Penny, Zheng wrote:
-Original Message-
From: Jan Beulich
Sent: Tuesday, June 17, 2025 12:00 AM
To: Penny, Zhe
On 7/4/2025 1:32 AM, Philippe Mathieu-Daudé wrote:
'dummy' helpers are specific to accelerator implementations,
no need to expose them via "system/cpus.h".
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Reviewed-by: Xiaoyao Li
On 03.07.25 19:35, Christophe JAILLET wrote:
Le 03/07/2025 à 07:22, Jürgen Groß a écrit :
On 03.07.25 00:42, Tu Dinh wrote:
On 01/07/2025 23:53, Abinash wrote:
Hi ,
Thanks for pointing that out.
I haven’t measured the performance impact yet — my main focus was on
getting rid of the stack usa
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Wednesday, July 2, 2025 6:48 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
On Tue, 1 Jul 2025, Dmytro Prokopchuk1 wrote:
> From: Federico Serafini
>
> MISRA C Rule 21.6 states that "The Standard Library input/output
> functions shall not be used".
>
> Xen does not use the functions provided by the Standard Library,
> uses -nostdlib to ensure this.
> Xen implements a se
On 6/11/25 5:34 PM, Chuck Zmudzinski wrote:
> On 6/10/25 12:22 AM, Jürgen Groß wrote:
>> On 10.06.25 00:43, Chuck Zmudzinski wrote:
>>> Hi,
>>>
>>> I am seeing the following regression between Linux 6.14.8 and 6.15.1.
>>>
>>> Kernel version 6.14.8 boots fine but version 6.15.1 crashes and
>>> reb
On Thu, 3 Jul 2025, Roger Pau Monné wrote:
> On Fri, Jun 27, 2025 at 07:08:29PM -0700, Stefano Stabellini wrote:
> > Hi Roger,
> >
> > We have an ARM board with the following memory layout:
> >
> > 0x0-0x8000, 0, 2G
> > 0x8,0x88000, 32GB, 2G
> > 0x500-0x5008000 5T, 2GB
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. i.e. the store to wake it up must also
>> identify the state.
>>
>> Cr
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 | 2 +-
include/accel/accel-ops.h | 50 +++
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/accel-cpu-ops.h_g \
$(git grep -l s
This method only accesses xen_domid/xen_domid_restrict, which are both
related to the 'accelerator', not the machine. Besides, xen_domid aims
to be in Xen AccelState and xen_domid_restrict a xen_domid_restrict
QOM property.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
Le 03/07/2025 à 07:22, Jürgen Groß a écrit :
On 03.07.25 00:42, Tu Dinh wrote:
On 01/07/2025 23:53, Abinash wrote:
Hi ,
Thanks for pointing that out.
I haven’t measured the performance impact yet — my main focus was on
getting rid of the stack usage warning triggered by LLVM due to
inlining.
In order to avoid init_machine() to call current_accel(),
pass AccelState along.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Reviewed-by: Alex Bennée
---
include/qemu/accel.h| 2 +-
accel/accel-system.c| 2 +-
accel/hvf/hvf-all.c | 2 +-
accel/k
'dummy' helpers are specific to accelerator implementations,
no need to expose them via "system/cpus.h".
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
MAINTAINERS | 1 +
accel/dummy-cpus.h| 14 ++
include/system/cpus.h | 5 -
accel/dumm
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 and register it
for each accelerator.
Suggested-by: Richard Henderson
On 03/07/2025 3:07 pm, Jan Beulich wrote:
> On 03.07.2025 13:59, Andrew Cooper wrote:
>> On 03/07/2025 10:01 am, Jan Beulich wrote:
>>> On 02.07.2025 16:41, Andrew Cooper wrote:
@@ -452,6 +466,10 @@ void mwait_idle_with_hints(unsigned int eax, unsigned
int ecx)
mwait(eax, e
On 7/3/25 04:55, Philippe Mathieu-Daudé wrote:
In order to dispatch overAccelOpsClass::handle_interrupt(),
we need it always defined, not calling a hidden handler under
the hood. MakeAccelOpsClass::handle_interrupt() mandatory.
Expose generic_handle_interrupt() prototype and register it
for each
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. i.e. the store to wake it up must also
> identify the state.
>
> Create a new in_mwait variable beside __softirq_pendin
On Wed, Jul 02, 2025 at 03:41:18PM +0100, Andrew Cooper wrote:
> x86 is the only architecture wanting an optimisation here, but the
> test_and_set_bit() is a store into the monitored line and is racy with
> determining whether an IPI can be skipped.
>
> Instead, implement a new arch helper with di
On 03/07/2025 5:01 pm, Roger Pau Monné wrote:
> On Wed, Jul 02, 2025 at 03:41:16PM +0100, Andrew Cooper wrote:
>> 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 sti
On Wed, Jul 02, 2025 at 03:41:16PM +0100, Andrew Cooper wrote:
> 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).
On 03.07.2025 13:59, Andrew Cooper wrote:
> On 03/07/2025 10:01 am, Jan Beulich wrote:
>> On 02.07.2025 16:41, Andrew Cooper wrote:
>>> @@ -452,6 +466,10 @@ void mwait_idle_with_hints(unsigned int eax, unsigned
>>> int ecx)
>>> mwait(eax, ecx);
>>> spec_ctrl_exit_idle(info);
>>>
On 03.07.2025 15:28, Oleksii Kurochko wrote:
>
> On 7/3/25 3:09 PM, Jan Beulich wrote:
>> On 03.07.2025 13:54, Oleksii Kurochko wrote:
>>> On 7/3/25 1:33 PM, Jan Beulich wrote:
On 03.07.2025 13:02, Oleksii Kurochko wrote:
> On 6/30/25 5:59 PM, Jan Beulich wrote:
>> On 10.06.2025 15:05
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 compiler barrier.
>>>
>>> Include this in monitor()
On 7/3/25 3:09 PM, Jan Beulich wrote:
On 03.07.2025 13:54, Oleksii Kurochko wrote:
On 7/3/25 1:33 PM, Jan Beulich wrote:
On 03.07.2025 13:02, Oleksii Kurochko wrote:
On 6/30/25 5:59 PM, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
+ unsigned l
On 03.07.2025 14:10, Andrew Cooper wrote:
> On 03/07/2025 10:43 am, Jan Beulich wrote:
>> On 02.07.2025 16:41, Andrew Cooper wrote:
>>> @@ -461,12 +468,19 @@ void mwait_idle_with_hints(unsigned int eax, unsigned
>>> int ecx)
>>>
>>> monitor(this_softirq_pending, 0, 0);
>>>
>>> +ASSERT
On 03.07.2025 13:54, Oleksii Kurochko wrote:
>
> On 7/3/25 1:33 PM, Jan Beulich wrote:
>> On 03.07.2025 13:02, Oleksii Kurochko wrote:
>>> On 6/30/25 5:59 PM, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
> + unsigned long nr, mfn_t mfn, p2m_
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 compiler barrier.
>>
>> Include this in monitor() itself, along with an explantion.
> Ah, here we
On 03/07/2025 10:43 am, Jan Beulich wrote:
> On 02.07.2025 16:41, Andrew Cooper wrote:
>> @@ -461,12 +468,19 @@ void mwait_idle_with_hints(unsigned int eax, unsigned
>> int ecx)
>>
>> monitor(this_softirq_pending, 0, 0);
>>
>> +ASSERT(!local_irq_is_enabled());
>> +
>> if ( !*this
On 03/07/2025 10:01 am, Jan Beulich wrote:
> On 02.07.2025 16:41, 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 vari
On 7/3/25 1:33 PM, Jan Beulich wrote:
On 03.07.2025 13:02, Oleksii Kurochko wrote:
On 6/30/25 5:59 PM, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
+ unsigned long nr, mfn_t mfn, p2m_type_t t)
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
On 03.07.2025 13:02, Oleksii Kurochko wrote:
> On 6/30/25 5:59 PM, Jan Beulich wrote:
>> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>>> + unsigned long nr, mfn_t mfn, p2m_type_t t)
>>> +{
>>> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>> +int rc;
>>> +
>>>
On 03.07.2025 12:36, Andrew Cooper wrote:
> On 03/07/2025 9:11 am, Jan Beulich wrote:
>> On 02.07.2025 16:41, Andrew Cooper wrote:
>>> x86 is the only architecture wanting an optimisation here, but the
>>> test_and_set_bit() is a store into the monitored line
>> Which is intentional aiui, while thi
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 cpu_get_clock() for each accelerator.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Pi
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 cpu_get_ticks() for each accelerator.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Pi
On 6/30/25 5:59 PM, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
+ unsigned long nr, mfn_t mfn, p2m_type_t t)
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+int rc;
+
+p2m_write_lock(p2m);
+rc = p2m_set_entry(p2m, start_gfn, nr,
In order to dispatch over AccelOpsClass::kick_vcpu_thread(),
we need it always defined, not calling a hidden handler under
the hood. Make AccelOpsClass::kick_vcpu_thread() mandatory.
Register the default cpus_kick_thread() for each accelerator.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: P
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 and register it
for each accelerator.
Suggested-by: Richard Henderson
By converting to AccelOpsClass::cpu_thread_routine we can
let the common accel_create_vcpu_thread() create the thread.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Acked-by: Fabiano Rosas
---
accel/dummy-cpus.h | 2 +-
accel/dummy-cpus.c | 14 +-
accel/qt
'dummy' helpers are specific to accelerator implementations,
no need to expose them via "system/cpus.h".
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
accel/dummy-cpus.h| 14 ++
include/system/cpus.h | 5 -
accel/dummy-cpus.c| 1 +
accel/qtes
This method only accesses xen_domid/xen_domid_restrict, which are both
related to the 'accelerator', not the machine. Besides, xen_domid aims
to be in Xen AccelState and xen_domid_restrict a xen_domid_restrict
QOM property.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
---
In order to avoid init_machine() to call current_accel(),
pass AccelState along.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Reviewed-by: Alex Bennée
---
include/qemu/accel.h| 2 +-
accel/accel-system.c| 2 +-
accel/hvf/hvf-accel-ops.c | 2 +-
accel/k
On 30.05.2025 15:17, Sergii Dmytruk wrote:
> Make head.S invoke a C function to retrieve MBI and SLRT addresses in a
> platform-specific way. This is also the place to perform sanity checks
> of DRTM.
>
> Signed-off-by: Krystian Hebel
> Signed-off-by: Sergii Dmytruk
> ---
> xen/arch/x86/Makefi
On 2/7/25 23:26, Pierrick Bouvier wrote:
On 7/2/25 11:53 AM, Philippe Mathieu-Daudé wrote:
In order to dispatch over AccelOpsClass::kick_vcpu_thread(),
we need it always defined, not calling a hidden handler under
the hood. Make AccelOpsClass::kick_vcpu_thread() mandatory.
Register the default c
On 03/07/2025 9:11 am, Jan Beulich wrote:
> On 02.07.2025 16:41, Andrew Cooper wrote:
>> x86 is the only architecture wanting an optimisation here, but the
>> test_and_set_bit() is a store into the monitored line
> Which is intentional aiui, while this reads as if this was part of the issue.
I don
On 30.05.2025 15:17, Sergii Dmytruk wrote:
> +#define SLAUNCH_BOOTLOADER_MAGIC 0x4c534254
Seeing how this is used in patch 3 - why does this live here?
According to the use there it's something entirely internal to Xen. It
could therefor be limited in scope to perhaps head.S or the boo
On 30.05.2025 15:17, Sergii Dmytruk wrote:
> From: Kacper Stojek
>
> Signed-off-by: Kacper Stojek
> Signed-off-by: Krystian Hebel
> Signed-off-by: Sergii Dmytruk
Such a change can hardly come without any description. As just one aspect,
neither here nor ...
> --- a/docs/hypervisor-guide/x86/
On Thu Jul 3, 2025 at 7:55 AM CEST, Jan Beulich wrote:
> On 02.07.2025 17:28, Alejandro Vallejo wrote:
>> On Wed Jul 2, 2025 at 3:30 PM CEST, Jan Beulich wrote:
>>> On 01.07.2025 12:57, Alejandro Vallejo wrote:
@@ -85,7 +86,11 @@ config HAS_ALTERNATIVE
config HAS_COMPAT
bool
On 03.07.2025 10:52, Julien Grall wrote:
> On 02/07/2025 14:37, Jan Beulich wrote:
>> On 02.07.2025 15:18, Julien Grall wrote:
>>> On 02/07/2025 14:06, Jan Beulich wrote:
When the bumping by (instead of just 1) was introduced, a comment
was left untouched, and a bogus ASSERT_UNREACHABLE(
On Thu Jul 3, 2025 at 8:01 AM CEST, Jan Beulich wrote:
> On 02.07.2025 18:04, Alejandro Vallejo wrote:
>> On Wed Jul 2, 2025 at 2:56 PM CEST, Jan Beulich wrote:
>>> On 01.07.2025 12:56, Alejandro Vallejo wrote:
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@
On 02.07.2025 16:41, Andrew Cooper wrote:
> @@ -461,12 +468,19 @@ void mwait_idle_with_hints(unsigned int eax, unsigned
> int ecx)
>
> monitor(this_softirq_pending, 0, 0);
>
> +ASSERT(!local_irq_is_enabled());
> +
> if ( !*this_softirq_pending )
> {
> struct cpu_inf
Hi Mykola,
> On Fri, Jun 27, 2025 at 01:51:31PM +, Mykola Kvach wrote:
> From: Mykola Kvach
>
> The "xl resume" command was previously excluded from ARM builds because
> system suspend/resume (e.g., `SYSTEM_SUSPEND`) via vPSCI was not
> implemented. On x86, the command is used for ACPI S3 su
On 02.07.2025 16:41, Andrew Cooper wrote:
> 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, whic
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 compiler barrier.
>
> Include this in monitor() itself, along with an explantion.
Ah, here we go. As per my comment on patch 4, would this perh
On 02.07.2025 16:41, 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_pending, so we can use a
>
Hi Jan,
On 02/07/2025 14:37, Jan Beulich wrote:
On 02.07.2025 15:18, Julien Grall wrote:
On 02/07/2025 14:06, Jan Beulich wrote:
When the bumping by (instead of just 1) was introduced, a comment
was left untouched, and a bogus ASSERT_UNREACHABLE() was inserted. That
code path can in principle
On Fri, Jun 27, 2025 at 07:08:29PM -0700, Stefano Stabellini wrote:
> Hi Roger,
>
> We have an ARM board with the following memory layout:
>
> 0x0-0x8000, 0, 2G
> 0x8,0x88000, 32GB, 2G
> 0x500-0x5008000 5T, 2GB
> 0x600-0x6008000 6T, 2GB
> 0x700-0x
On Wed, Jul 02, 2025 at 08:53:18PM +0200, Philippe Mathieu-Daudé wrote:
> Date: Wed, 2 Jul 2025 20:53:18 +0200
> From: Philippe Mathieu-Daudé
> Subject: [PATCH v4 56/65] accel: Expose and register
> generic_handle_interrupt()
> X-Mailer: git-send-email 2.49.0
>
> In order to dispatch over Accel
On Wed, Jul 02, 2025 at 08:53:21PM +0200, Philippe Mathieu-Daudé wrote:
> Date: Wed, 2 Jul 2025 20:53:21 +0200
> From: Philippe Mathieu-Daudé
> Subject: [PATCH v4 59/65] accel: Always register
> AccelOpsClass::get_virtual_clock() handler
> X-Mailer: git-send-email 2.49.0
>
> In order to dispatc
On Wed, Jul 02, 2025 at 08:53:20PM +0200, Philippe Mathieu-Daudé wrote:
> Date: Wed, 2 Jul 2025 20:53:20 +0200
> From: Philippe Mathieu-Daudé
> Subject: [PATCH v4 58/65] accel: Always register
> AccelOpsClass::get_elapsed_ticks() handler
> X-Mailer: git-send-email 2.49.0
>
> In order to dispatc
On Wed, Jul 02, 2025 at 08:53:19PM +0200, Philippe Mathieu-Daudé wrote:
> Date: Wed, 2 Jul 2025 20:53:19 +0200
> From: Philippe Mathieu-Daudé
> Subject: [PATCH v4 57/65] accel: Always register
> AccelOpsClass::kick_vcpu_thread() handler
> X-Mailer: git-send-email 2.49.0
>
> In order to dispatch
On 02.07.2025 16:41, Andrew Cooper wrote:
> x86 is the only architecture wanting an optimisation here, but the
> test_and_set_bit() is a store into the monitored line
Which is intentional aiui, while this reads as if this was part of the issue.
> and is racy with determining whether an IPI can be
When compiling the kernel with LLVM, the following warning was issued:
drivers/xen/gntdev.c:991: warning: stack frame size (1160) exceeds
limit (1024) in function 'gntdev_ioctl'
The main reason is struct gntdev_copy_batch which is located on the
stack and has a size of nearly 1kb.
For perfor
64 matches
Mail list logo
