For some reason, there are some TSC-related functions in the MSR
header even though there is a tsc.h header.
To facilitate the relocation of rdtsc{,_ordered}() from
to and to eventually eliminate the inclusion of
in , add to the source files that
reference definitions from .
Signed-off-by: Xi
The patch series needs to be rebased. Actually, I couldn't find a
baseline where to apply patch #2 successfully
On Mon, 14 Apr 2025, Oleksii Kurochko wrote:
> Some parts of Arm's Dom0less solution could be moved to common code as they
> are
> not truly Arm-specific.
>
> Most of the code is moved
On Wed, 30 Apr 2025, Jan Beulich wrote:
> On 30.04.2025 00:54, Stefano Stabellini wrote:
> > On Tue, 29 Apr 2025, Jan Beulich wrote:
> >> On 29.04.2025 03:27, Stefano Stabellini wrote:
> >>> On Mon, 28 Apr 2025, Jan Beulich wrote:
> On 26.04.2025 01:42, [email protected] wrote:
> > From
On Wed, 30 Apr 2025, Roger Pau Monné wrote:
> On Wed, Apr 30, 2025 at 08:27:55AM +0200, Jan Beulich wrote:
> > On 29.04.2025 23:52, Stefano Stabellini wrote:
> > > On Tue, 29 Apr 2025, Jan Beulich wrote:
> > >> On 28.04.2025 22:00, Stefano Stabellini wrote:
> > >>> On Mon, 28 Apr 2025, Jan Beulich
On Tue, 28 Apr 2025, Andrew Cooper wrote:
> On 29/04/2025 9:16 am, Jan Beulich wrote:
> > Multicall compat translation and hypercall continuation handling can
> > also be shrunk to the processing of just (up to) 5 arguments.
> >
> > Take the opportunity to
> > - make exceeding the limit noisy in hy
On 4/29/25 08:36, Alejandro Vallejo wrote:
From: "Daniel P. Smith"
Introduce the domain builder which is capable of consuming a device tree as the
first boot module. If it finds a device tree as the first boot module, it will
set its type to BOOTMOD_FDT. This change only detects the boot module
On 4/30/2025 2:17 AM, Ilpo Järvinen wrote:
While this is not my subsystem so don't have the final say here, you had
to explain quite much to prove that (and reviewer would have to go through
the same places to check). Wouldn't it be much simpler for all if all
those .c files would just include d
On 30/04/2025 5:05 pm, Jan Beulich wrote:
> On 30.04.2025 18:00, Andrew Cooper wrote:
>> On 30/04/2025 2:13 pm, Jan Beulich wrote:
>>> In a number of cases we use ALTERNATIVE_2 with both replacement insns /
>>> insn sequences being identical. Avoid emitting the same code twice, and
>>> instead alia
On 4/28/25 10:54 AM, Jan Beulich wrote:
+ASSERT(spin_is_locked(&desc->lock));
If this lock (which is an IRQ-safe one) is necessarily held, ...
+spin_lock_irqsave(&aplic.lock, flags);
... you can use just spin_lock() here.
+clear_bit(_IRQ_DISABLED, &desc->status);
Why an atomic
On 30.04.2025 18:00, Andrew Cooper wrote:
> On 30/04/2025 2:13 pm, Jan Beulich wrote:
>> In a number of cases we use ALTERNATIVE_2 with both replacement insns /
>> insn sequences being identical. Avoid emitting the same code twice, and
>> instead alias the necessary helper labels to the existing on
On 30/04/2025 4:56 pm, Jan Beulich wrote:
> There's nothing arch-specific about it.
>
> While there, on x86 visually separate the vmap_to_*() macros from those
> covered by the earlier comment.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 30/04/2025 2:13 pm, Jan Beulich wrote:
> In a number of cases we use ALTERNATIVE_2 with both replacement insns /
> insn sequences being identical. Avoid emitting the same code twice, and
> instead alias the necessary helper labels to the existing ones.
>
> Signed-off-by: Jan Beulich
On a rando
On 18.04.2025 16:18, Teddy Astie wrote:
> @@ -745,6 +747,12 @@ static int sanitise_domain_config(struct
> xen_domctl_createdomain *config)
> return -EINVAL;
> }
>
> +if ( physaddr_abi && !hvm )
> +{
> +dprintk(XENLOG_INFO, "Physical address ABI requested for non-HVM
There's nothing arch-specific about it.
While there, on x86 visually separate the vmap_to_*() macros from those
covered by the earlier comment.
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -237,7 +237,6 @@ static inline void __iomem *iore
On 30.04.2025 17:20, Jan Beulich wrote:
> On 21.04.2025 09:37, Penny Zheng wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -581,4 +581,15 @@ config BUDDY_ALLOCATOR_SIZE
>>Amount of memory reserved for the buddy allocator to serve Xen heap,
>>working alongside th
On 21.04.2025 09:37, Penny Zheng wrote:
> --- a/xen/arch/riscv/stubs.c
> +++ b/xen/arch/riscv/stubs.c
> @@ -315,13 +315,13 @@ unsigned long raw_copy_from_guest(void *to, const void
> __user *from,
>
> /* sysctl.c */
>
> +#ifdef CONFIG_SYSCTL
> long arch_do_sysctl(struct xen_sysctl *sysctl,
>
On 30.04.25 16:29, Jason Andryuk wrote:
On 2025-04-30 06:56, Marek Marczykowski-Górecki wrote:
On Tue, Apr 29, 2025 at 08:59:45PM -0400, Jason Andryuk wrote:
Hi Marek,
On Wed, Apr 23, 2025 at 8:42 AM Marek Marczykowski-Górecki
wrote:
I've got some more report confirming it's still happenin
On 30.04.2025 17:34, Oleksii Kurochko wrote:
>
> On 4/17/25 12:11 PM, Oleksii Kurochko wrote:
>>
>>
>> On 4/15/25 5:59 PM, Jan Beulich wrote:
>>> On 08.04.2025 17:57, Oleksii Kurochko wrote:
Call intc_init() to do basic initialization steps for APLIC and IMISC.
Signed-off-by: Oleksi
On 21.04.2025 23:12, Stefano Stabellini wrote:
> On Mon, 21 Apr 2025, Penny Zheng wrote:
>> 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-re
On 4/17/25 12:11 PM, Oleksii Kurochko wrote:
On 4/15/25 5:59 PM, Jan Beulich wrote:
On 08.04.2025 17:57, Oleksii Kurochko wrote:
Call intc_init() to do basic initialization steps for APLIC and IMISC.
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
yet ...
--- a/xen/arch/riscv/setup
On 30.04.2025 17:27, Andrew Cooper wrote:
> They're only modified by set_in_mcu_opt_ctrl() which is an __init function.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 21.04.2025 09:37, Penny Zheng wrote:
> 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()
>
They're only modified by set_in_mcu_opt_ctrl() which is an __init function.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
In principle:
Fixes: 39a40f3835ef ("x86/spec-ctrl: Clean up MSR_MCU_OPT_CTRL handling")
seeing as __ro_after_init existed a
On 21.04.2025 09:37, Penny Zheng wrote:
> We move the following functions into drivers/acpi/pmstat.c, as they
> are all designed for performance statistic:
> - cpufreq_residency_update
> - cpufreq_statistic_reset
> - cpufreq_statistic_update
> - cpufreq_statistic_init
> - cpufreq_statistic_exit
> C
On 21.04.2025 09:37, Penny Zheng wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -581,4 +581,15 @@ config BUDDY_ALLOCATOR_SIZE
> Amount of memory reserved for the buddy allocator to serve Xen heap,
> working alongside the colored one.
>
> +menu "Supported hyperca
On 21.04.2025 09:37, Penny Zheng wrote:
> Remove all "depends on !PV_SHIM_EXCLUSIVE" (also the functionally
> equivalent "if !...") in Kconfig file, since negative dependancy will badly
> affect allyesconfig.
> This commit is based on "x86: provide an inverted Kconfig control for
> shim-exclusive m
On 21.04.2025 09:37, Penny Zheng wrote:
> From: Stefano Stabellini
>
> We introduce a new Kconfig CONFIG_SYSCTL, which shall only be disabled
> on some dom0less systems, to reduce Xen footprint.
What about the PV shim on x86? That's also relevant ...
> --- a/xen/common/Kconfig
> +++ b/xen/commo
On 14.04.2025 09:40, Penny Zheng wrote:
> Introduce helper set_amd_cppc_para and get_amd_cppc_para to
> SET/GET CPPC-related para for amd-cppc/amd-cppc-epp driver.
>
> Signed-off-by: Penny Zheng
> ---
> v1 -> v2:
> - Give the variable des_perf an initializer of 0
> - Use the strncmp()s directly i
On 14.04.2025 09:40, Penny Zheng wrote:
> In `xenpm start` command, the monitor of average frequency shall
> not depend on the existence of legacy P-states, so removing "px_cap"
> dependancy check.
Well, yes, I agree there. But can you explain to me what the file scope
"avgfreq" is good for? Shoul
On 2025-04-30 06:56, Marek Marczykowski-Górecki wrote:
On Tue, Apr 29, 2025 at 08:59:45PM -0400, Jason Andryuk wrote:
Hi Marek,
On Wed, Apr 23, 2025 at 8:42 AM Marek Marczykowski-Górecki
wrote:
I've got some more report confirming it's still happening on Linux
6.12.18. Is there anything I c
On 14.04.2025 09:40, Penny Zheng wrote:
> In `xenpm get-cpufreq-para `, para scaling_available_frequencies
> only has meaningful value when cpufreq driver in legacy P-states mode.
>
> So we drop the "has_num" condition check, and mirror the ->gov_num check for
> both ->freq_num and ->cpu_num in xc
On 14.04.2025 09:40, Penny Zheng wrote:
> HWP, amd-cppc, amd-cppc-epp are all the implementation
> of ACPI CPPC (Collaborative Processor Performace Control),
> so we introduce cppc_mode flag to print CPPC-related para.
>
> And HWP and amd-cppc-epp are both governor-less driver,
> so we introduce h
In a number of cases we use ALTERNATIVE_2 with both replacement insns /
insn sequences being identical. Avoid emitting the same code twice, and
instead alias the necessary helper labels to the existing ones.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/include/asm/alternative-asm.h
+++ b/xen/ar
Hi Michal,
> On 30 Apr 2025, at 11:57, Orzel, Michal wrote:
>
>
>
> On 29/04/2025 17:20, Luca Fancellu wrote:
>> Provide some data structure in the C world to track the MPU
>> status, these structures will be filled at boot by the assembly
>> early code with the boot MPU regions and afterwards
Jan Beulich writes:
> On 30.04.2025 04:17, Volodymyr Babchuk wrote:
>> Julien Grall writes:
--- /dev/null
+++ b/xen/arch/arm/include/asm/libafl_qemu_defs.h
@@ -0,0 +1,37 @@
>>>
>>> Missing license. Also, is this file taken from somewhere?
>>>
>>
>> I add MIT license, as libafl is
On 29/04/2025 17:20, Luca Fancellu wrote:
> Provide some data structure in the C world to track the MPU
> status, these structures will be filled at boot by the assembly
> early code with the boot MPU regions and afterwards they will be
> used at runtime.
>
> Provide methods to update a bitmap
On Tue, Apr 29, 2025 at 08:59:45PM -0400, Jason Andryuk wrote:
> Hi Marek,
>
> On Wed, Apr 23, 2025 at 8:42 AM Marek Marczykowski-Górecki
> wrote:
> >
> > On Sat, Jun 01, 2024 at 12:48:33AM +0200, Marek Marczykowski-Górecki wrote:
> > > On Tue, Mar 26, 2024 at 11:00:50AM +, Julien Grall wrote
On Wed, 30 Apr 2025, Xin Li wrote:
> On 4/29/2025 2:45 AM, Ilpo Järvinen wrote:
> > > arch/x86/events/msr.c | 3 +++
> > > arch/x86/events/perf_event.h | 1 +
> > > arch/x86/events/probe.c
On 4/29/2025 9:20 PM, Michael Kelley wrote:
Also under hyperv/ not all files are covered but I'm a bit hesitant to
suggest a change there since I'm not sure if they (hypervisors) do
something special w.r.t. msr.
I've worked on the Hyper-V code in Linux for 8 years or so, first as
a Microsoft emp
On 4/29/2025 2:45 AM, Ilpo Järvinen wrote:
arch/x86/events/msr.c | 3 +++
arch/x86/events/perf_event.h | 1 +
arch/x86/events/probe.c | 2 ++
Under arch/x86/events/ a few files seem
On Wed, Apr 30, 2025 at 08:27:55AM +0200, Jan Beulich wrote:
> On 29.04.2025 23:52, Stefano Stabellini wrote:
> > On Tue, 29 Apr 2025, Jan Beulich wrote:
> >> On 28.04.2025 22:00, Stefano Stabellini wrote:
> >>> On Mon, 28 Apr 2025, Jan Beulich wrote:
> On 25.04.2025 22:19, Stefano Stabellini
Hi Michal,
>>>
>>> Is the goal of this patch to only write firmware/bootloader requirements or
>>> accommodate booting protocol in general? Asking because in this file there
>>> is a
>>> requirement that Xen should be loaded below 10TB which afaict does not fit
>>> Armv8-R.
>>
>> Yes you are r
Hi Michal,
> On 30 Apr 2025, at 07:37, Orzel, Michal wrote:
>
>
>
> On 29/04/2025 17:20, Luca Fancellu wrote:
>> Document the requirement needed to boot Xen on Armv8-R platforms.
>>
>> Signed-off-by: Luca Fancellu
>> ---
>> v4 changes:
>> - New patch
>> ---
>> docs/misc/arm/booting.txt | 8 +
On 30/04/2025 08:58, Luca Fancellu wrote:
> Hi Michal,
>
>> On 30 Apr 2025, at 07:37, Orzel, Michal wrote:
>>
>>
>>
>> On 29/04/2025 17:20, Luca Fancellu wrote:
>>> Document the requirement needed to boot Xen on Armv8-R platforms.
>>>
>>> Signed-off-by: Luca Fancellu
>>> ---
>>> v4 changes:
>
44 matches
Mail list logo
