- Linux-stable-mirror - lists.linaro.org

[PATCH AUTOSEL 5.4] x86/hyperv: Set X86_FEATURE_TSC_KNOWN_FREQ when Hyper-V provides frequency

by Sasha Levin

From: Michael Kelley <mhklinux(a)outlook.com> [ Upstream commit 8fcc514809de41153b43ccbe1a0cdf7f72b78e7e ] A Linux guest on Hyper-V gets the TSC frequency from a synthetic MSR, if available. In this case, set X86_FEATURE_TSC_KNOWN_FREQ so that Linux doesn't unnecessarily do refined TSC calibration when setting up the TSC clocksource. With this change, a message such as this is no longer output during boot when the TSC is used as the clocksource: [ 1.115141] tsc: Refined TSC clocksource calibration: 2918.408 MHz Furthermore, the guest and host will have exactly the same view of the TSC frequency, which is important for features such as the TSC deadline timer that are emulated by the Hyper-V host. Signed-off-by: Michael Kelley <mhklinux(a)outlook.com> Reviewed-by: Roman Kisel <romank(a)linux.microsoft.com> Link: https://lore.kernel.org/r/20240606025559.1631-1-mhklinux@outlook.com Signed-off-by: Wei Liu <wei.liu(a)kernel.org> Message-ID: <20240606025559.1631-1-mhklinux(a)outlook.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/x86/kernel/cpu/mshyperv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c index 51d95c4b692c..cebbcc6c36ae 100644 --- a/arch/x86/kernel/cpu/mshyperv.c +++ b/arch/x86/kernel/cpu/mshyperv.c @@ -256,6 +256,7 @@ static void __init ms_hyperv_init_platform(void) ms_hyperv.misc_features & HV_FEATURE_FREQUENCY_MSRS_AVAILABLE) { x86_platform.calibrate_tsc = hv_get_tsc_khz; x86_platform.calibrate_cpu = hv_get_tsc_khz; + setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); } if (ms_hyperv.hints & HV_X64_ENLIGHTENED_VMCS_RECOMMENDED) { -- 2.43.0

12 months

1
0
0 0

[PATCH AUTOSEL 5.10] x86/hyperv: Set X86_FEATURE_TSC_KNOWN_FREQ when Hyper-V provides frequency

by Sasha Levin

From: Michael Kelley <mhklinux(a)outlook.com> [ Upstream commit 8fcc514809de41153b43ccbe1a0cdf7f72b78e7e ] A Linux guest on Hyper-V gets the TSC frequency from a synthetic MSR, if available. In this case, set X86_FEATURE_TSC_KNOWN_FREQ so that Linux doesn't unnecessarily do refined TSC calibration when setting up the TSC clocksource. With this change, a message such as this is no longer output during boot when the TSC is used as the clocksource: [ 1.115141] tsc: Refined TSC clocksource calibration: 2918.408 MHz Furthermore, the guest and host will have exactly the same view of the TSC frequency, which is important for features such as the TSC deadline timer that are emulated by the Hyper-V host. Signed-off-by: Michael Kelley <mhklinux(a)outlook.com> Reviewed-by: Roman Kisel <romank(a)linux.microsoft.com> Link: https://lore.kernel.org/r/20240606025559.1631-1-mhklinux@outlook.com Signed-off-by: Wei Liu <wei.liu(a)kernel.org> Message-ID: <20240606025559.1631-1-mhklinux(a)outlook.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/x86/kernel/cpu/mshyperv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c index 021cd067733e..a91aad434d03 100644 --- a/arch/x86/kernel/cpu/mshyperv.c +++ b/arch/x86/kernel/cpu/mshyperv.c @@ -275,6 +275,7 @@ static void __init ms_hyperv_init_platform(void) ms_hyperv.misc_features & HV_FEATURE_FREQUENCY_MSRS_AVAILABLE) { x86_platform.calibrate_tsc = hv_get_tsc_khz; x86_platform.calibrate_cpu = hv_get_tsc_khz; + setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); } if (ms_hyperv.hints & HV_X64_ENLIGHTENED_VMCS_RECOMMENDED) { -- 2.43.0

12 months

1
0
0 0

[PATCH AUTOSEL 5.15] x86/hyperv: Set X86_FEATURE_TSC_KNOWN_FREQ when Hyper-V provides frequency

by Sasha Levin

From: Michael Kelley <mhklinux(a)outlook.com> [ Upstream commit 8fcc514809de41153b43ccbe1a0cdf7f72b78e7e ] A Linux guest on Hyper-V gets the TSC frequency from a synthetic MSR, if available. In this case, set X86_FEATURE_TSC_KNOWN_FREQ so that Linux doesn't unnecessarily do refined TSC calibration when setting up the TSC clocksource. With this change, a message such as this is no longer output during boot when the TSC is used as the clocksource: [ 1.115141] tsc: Refined TSC clocksource calibration: 2918.408 MHz Furthermore, the guest and host will have exactly the same view of the TSC frequency, which is important for features such as the TSC deadline timer that are emulated by the Hyper-V host. Signed-off-by: Michael Kelley <mhklinux(a)outlook.com> Reviewed-by: Roman Kisel <romank(a)linux.microsoft.com> Link: https://lore.kernel.org/r/20240606025559.1631-1-mhklinux@outlook.com Signed-off-by: Wei Liu <wei.liu(a)kernel.org> Message-ID: <20240606025559.1631-1-mhklinux(a)outlook.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/x86/kernel/cpu/mshyperv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c index 8d3c649a1769..3794b223fd69 100644 --- a/arch/x86/kernel/cpu/mshyperv.c +++ b/arch/x86/kernel/cpu/mshyperv.c @@ -322,6 +322,7 @@ static void __init ms_hyperv_init_platform(void) ms_hyperv.misc_features & HV_FEATURE_FREQUENCY_MSRS_AVAILABLE) { x86_platform.calibrate_tsc = hv_get_tsc_khz; x86_platform.calibrate_cpu = hv_get_tsc_khz; + setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); } if (ms_hyperv.priv_high & HV_ISOLATION) { -- 2.43.0

12 months

1
0
0 0

[PATCH AUTOSEL 6.1 1/2] x86/hyperv: Set X86_FEATURE_TSC_KNOWN_FREQ when Hyper-V provides frequency

by Sasha Levin

From: Michael Kelley <mhklinux(a)outlook.com> [ Upstream commit 8fcc514809de41153b43ccbe1a0cdf7f72b78e7e ] A Linux guest on Hyper-V gets the TSC frequency from a synthetic MSR, if available. In this case, set X86_FEATURE_TSC_KNOWN_FREQ so that Linux doesn't unnecessarily do refined TSC calibration when setting up the TSC clocksource. With this change, a message such as this is no longer output during boot when the TSC is used as the clocksource: [ 1.115141] tsc: Refined TSC clocksource calibration: 2918.408 MHz Furthermore, the guest and host will have exactly the same view of the TSC frequency, which is important for features such as the TSC deadline timer that are emulated by the Hyper-V host. Signed-off-by: Michael Kelley <mhklinux(a)outlook.com> Reviewed-by: Roman Kisel <romank(a)linux.microsoft.com> Link: https://lore.kernel.org/r/20240606025559.1631-1-mhklinux@outlook.com Signed-off-by: Wei Liu <wei.liu(a)kernel.org> Message-ID: <20240606025559.1631-1-mhklinux(a)outlook.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/x86/kernel/cpu/mshyperv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c index 9b039e9635e4..542b818c0d20 100644 --- a/arch/x86/kernel/cpu/mshyperv.c +++ b/arch/x86/kernel/cpu/mshyperv.c @@ -324,6 +324,7 @@ static void __init ms_hyperv_init_platform(void) ms_hyperv.misc_features & HV_FEATURE_FREQUENCY_MSRS_AVAILABLE) { x86_platform.calibrate_tsc = hv_get_tsc_khz; x86_platform.calibrate_cpu = hv_get_tsc_khz; + setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); } if (ms_hyperv.priv_high & HV_ISOLATION) { -- 2.43.0

12 months

1
1
0 0

[PATCH AUTOSEL 6.6 1/2] x86/hyperv: Set X86_FEATURE_TSC_KNOWN_FREQ when Hyper-V provides frequency

by Sasha Levin

From: Michael Kelley <mhklinux(a)outlook.com> [ Upstream commit 8fcc514809de41153b43ccbe1a0cdf7f72b78e7e ] A Linux guest on Hyper-V gets the TSC frequency from a synthetic MSR, if available. In this case, set X86_FEATURE_TSC_KNOWN_FREQ so that Linux doesn't unnecessarily do refined TSC calibration when setting up the TSC clocksource. With this change, a message such as this is no longer output during boot when the TSC is used as the clocksource: [ 1.115141] tsc: Refined TSC clocksource calibration: 2918.408 MHz Furthermore, the guest and host will have exactly the same view of the TSC frequency, which is important for features such as the TSC deadline timer that are emulated by the Hyper-V host. Signed-off-by: Michael Kelley <mhklinux(a)outlook.com> Reviewed-by: Roman Kisel <romank(a)linux.microsoft.com> Link: https://lore.kernel.org/r/20240606025559.1631-1-mhklinux@outlook.com Signed-off-by: Wei Liu <wei.liu(a)kernel.org> Message-ID: <20240606025559.1631-1-mhklinux(a)outlook.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/x86/kernel/cpu/mshyperv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c index e6bba12c759c..9a7cd3ce59ed 100644 --- a/arch/x86/kernel/cpu/mshyperv.c +++ b/arch/x86/kernel/cpu/mshyperv.c @@ -423,6 +423,7 @@ static void __init ms_hyperv_init_platform(void) ms_hyperv.misc_features & HV_FEATURE_FREQUENCY_MSRS_AVAILABLE) { x86_platform.calibrate_tsc = hv_get_tsc_khz; x86_platform.calibrate_cpu = hv_get_tsc_khz; + setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); } if (ms_hyperv.priv_high & HV_ISOLATION) { -- 2.43.0

12 months

1
1
0 0

[PATCH AUTOSEL 6.10 1/3] x86/hyperv: Set X86_FEATURE_TSC_KNOWN_FREQ when Hyper-V provides frequency

by Sasha Levin

From: Michael Kelley <mhklinux(a)outlook.com> [ Upstream commit 8fcc514809de41153b43ccbe1a0cdf7f72b78e7e ] A Linux guest on Hyper-V gets the TSC frequency from a synthetic MSR, if available. In this case, set X86_FEATURE_TSC_KNOWN_FREQ so that Linux doesn't unnecessarily do refined TSC calibration when setting up the TSC clocksource. With this change, a message such as this is no longer output during boot when the TSC is used as the clocksource: [ 1.115141] tsc: Refined TSC clocksource calibration: 2918.408 MHz Furthermore, the guest and host will have exactly the same view of the TSC frequency, which is important for features such as the TSC deadline timer that are emulated by the Hyper-V host. Signed-off-by: Michael Kelley <mhklinux(a)outlook.com> Reviewed-by: Roman Kisel <romank(a)linux.microsoft.com> Link: https://lore.kernel.org/r/20240606025559.1631-1-mhklinux@outlook.com Signed-off-by: Wei Liu <wei.liu(a)kernel.org> Message-ID: <20240606025559.1631-1-mhklinux(a)outlook.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/x86/kernel/cpu/mshyperv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c index e0fd57a8ba84..c3e38eaf6d2f 100644 --- a/arch/x86/kernel/cpu/mshyperv.c +++ b/arch/x86/kernel/cpu/mshyperv.c @@ -424,6 +424,7 @@ static void __init ms_hyperv_init_platform(void) ms_hyperv.misc_features & HV_FEATURE_FREQUENCY_MSRS_AVAILABLE) { x86_platform.calibrate_tsc = hv_get_tsc_khz; x86_platform.calibrate_cpu = hv_get_tsc_khz; + setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); } if (ms_hyperv.priv_high & HV_ISOLATION) { -- 2.43.0

12 months

1
2
0 0

[PATCH 1/1] io_uring/sqpoll: do not allow pinning outside of cpuset

by Felix Moessbauer

The submit queue polling threads are userland threads that just never exit to the userland. When creating the thread with IORING_SETUP_SQ_AFF, the affinity of the poller thread is set to the cpu specified in sq_thread_cpu. However, this CPU can be outside of the cpuset defined by the cgroup cpuset controller. This violates the rules defined by the cpuset controller and is a potential issue for realtime applications. In b7ed6d8ffd6 we fixed the default affinity of the poller thread, in case no explicit pinning is required by inheriting the one of the creating task. In case of explicit pinning, the check is more complicated, as also a cpu outside of the parent cpumask is allowed. We implemented this by using cpuset_cpus_allowed (that has support for cgroup cpusets) and testing if the requested cpu is in the set. Fixes: 37d1e2e3642e ("io_uring: move SQPOLL thread io-wq forked worker") Cc: stable(a)vger.kernel.org # 6.1+ Signed-off-by: Felix Moessbauer <felix.moessbauer(a)siemens.com> --- Hi, that's hopefully the last fix of cpu pinnings of the sq poller threads. However, there is more to come on the io-wq side. E.g the syscalls for IORING_REGISTER_IOWQ_AFF that can be used to change the affinites are not yet protected. I'm currently just lacking good reproducers for that. I also have to admit that I don't feel too comfortable making changes to the wq part, given that I don't have good tests. While fixing this, I'm wondering if it makes sense to add tests for the combination of pinning and cpuset. If yes, where should these tests be added? Best regards, Felix Moessbauer Siemens AG io_uring/sqpoll.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/io_uring/sqpoll.c b/io_uring/sqpoll.c index 713be7c29388..b8ec8fec99b8 100644 --- a/io_uring/sqpoll.c +++ b/io_uring/sqpoll.c @@ -10,6 +10,7 @@ #include <linux/slab.h> #include <linux/audit.h> #include <linux/security.h> +#include <linux/cpuset.h> #include <linux/io_uring.h> #include <uapi/linux/io_uring.h> @@ -459,10 +460,12 @@ __cold int io_sq_offload_create(struct io_ring_ctx *ctx, return 0; if (p->flags & IORING_SETUP_SQ_AFF) { + struct cpumask allowed_mask; int cpu = p->sq_thread_cpu; ret = -EINVAL; - if (cpu >= nr_cpu_ids || !cpu_online(cpu)) + cpuset_cpus_allowed(current, &allowed_mask); + if (!cpumask_test_cpu(cpu, &allowed_mask)) goto err_sqpoll; sqd->sq_cpu = cpu; } else { -- 2.39.2

12 months

3
5
0 0

RE: Patch "riscv: dts: starfive: jh7110-common: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz" has been added to the 6.10-stable tree

by Xingyu Wu

On 13/09/2024 22:12, Sasha Levin wrote: > > This is a note to let you know that I've just added the patch titled > > riscv: dts: starfive: jh7110-common: Fix lower rate of CPUfreq by setting PLL0 > rate to 1.5GHz > > to the 6.10-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable- > queue.git;a=summary > > The filename of the patch is: > riscv-dts-starfive-jh7110-common-fix-lower-rate-of-c.patch > and it can be found in the queue-6.10 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, please let > <stable(a)vger.kernel.org> know about it. > Hi Sasha, This patch only has the part of DTS without the clock driver patch[1]. [1]: https://lore.kernel.org/all/20240826080430.179788-2-xingyu.wu@starfivetech.… I don't know your plan about this driver patch, or maybe I missed it. But the DTS changes really needs the driver patch to work and you should add the driver patch. Thanks, Xingyu Wu > > > commit 67b60bf9777bd340c7179adb5376dcdd3f0c260c > Author: Xingyu Wu <xingyu.wu(a)starfivetech.com> > Date: Mon Aug 26 16:04:30 2024 +0800 > > riscv: dts: starfive: jh7110-common: Fix lower rate of CPUfreq by setting PLL0 > rate to 1.5GHz > > [ Upstream commit 61f2e8a3a94175dbbaad6a54f381b2a505324610 ] > > CPUfreq supports 4 cpu frequency loads on 375/500/750/1500MHz. > But now PLL0 rate is 1GHz and the cpu frequency loads become > 250/333/500/1000MHz in fact. > > The PLL0 rate should be default set to 1.5GHz and set the > cpu_core rate to 500MHz in safe. > > Fixes: e2c510d6d630 ("riscv: dts: starfive: Add cpu scaling for JH7110 SoC") > Signed-off-by: Xingyu Wu <xingyu.wu(a)starfivetech.com> > Reviewed-by: Hal Feng <hal.feng(a)starfivetech.com> > Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi > b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi > index 68d16717db8c..51d85f447626 100644 > --- a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi > +++ b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi > @@ -354,6 +354,12 @@ spi_dev0: spi@0 { > }; > }; > > +&syscrg { > + assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>, > + <&pllclk JH7110_PLLCLK_PLL0_OUT>; > + assigned-clock-rates = <500000000>, <1500000000>; }; > + > &sysgpio { > i2c0_pins: i2c0-0 { > i2c-pins {

12 months

3
11
0 0

[PATCH v2] riscv: entry: always initialize regs->a0 to -ENOSYS

by Celeste Liu

Otherwise when the tracer changes syscall number to -1, the kernel fails to initialize a0 with -ENOSYS and subsequently fails to return the error code of the failed syscall to userspace. For example, it will break strace syscall tampering. Fixes: 52449c17bdd1 ("riscv: entry: set a0 = -ENOSYS only when syscall != -1") Reported-by: "Dmitry V. Levin" <ldv(a)strace.io> Reviewed-by: Björn Töpel <bjorn(a)rivosinc.com> Cc: stable(a)vger.kernel.org Signed-off-by: Celeste Liu <CoelacanthusHex(a)gmail.com> --- arch/riscv/kernel/traps.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c index 05a16b1f0aee..51ebfd23e007 100644 --- a/arch/riscv/kernel/traps.c +++ b/arch/riscv/kernel/traps.c @@ -319,6 +319,7 @@ void do_trap_ecall_u(struct pt_regs *regs) regs->epc += 4; regs->orig_a0 = regs->a0; + regs->a0 = -ENOSYS; riscv_v_vstate_discard(regs); @@ -328,8 +329,7 @@ void do_trap_ecall_u(struct pt_regs *regs) if (syscall >= 0 && syscall < NR_syscalls) syscall_handler(regs, syscall); - else if (syscall != -1) - regs->a0 = -ENOSYS; + /* * Ultimately, this value will get limited by KSTACK_OFFSET_MAX(), * so the maximum stack offset is 1k bytes (10 bits). -- 2.45.2

12 months

4
3
0 0

[PATCH] Revert "vmgenid: emit uevent when VMGENID updates"

by Jason A. Donenfeld

This reverts commit ad6bcdad2b6724e113f191a12f859a9e8456b26d. I had nak'd it, and Greg said on the thread that it links that he wasn't going to take it either, especially since it's not his code or his tree, but then, seemingly accidentally, it got pushed up some months later, in what looks like a mistake, with no further discussion in the linked thread. So revert it, since it's clearly not intended. Fixes: ad6bcdad2b67 ("vmgenid: emit uevent when VMGENID updates") Cc: stable(a)vger.kernel.org Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20230531095119.11202-2-bchalios@amazon.es Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> --- drivers/virt/vmgenid.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/virt/vmgenid.c b/drivers/virt/vmgenid.c index b67a28da4702..a1c467a0e9f7 100644 --- a/drivers/virt/vmgenid.c +++ b/drivers/virt/vmgenid.c @@ -68,7 +68,6 @@ static int vmgenid_add(struct acpi_device *device) static void vmgenid_notify(struct acpi_device *device, u32 event) { struct vmgenid_state *state = acpi_driver_data(device); - char *envp[] = { "NEW_VMGENID=1", NULL }; u8 old_id[VMGENID_SIZE]; memcpy(old_id, state->this_id, sizeof(old_id)); @@ -76,7 +75,6 @@ static void vmgenid_notify(struct acpi_device *device, u32 event) if (!memcmp(old_id, state->this_id, sizeof(old_id))) return; add_vmfork_randomness(state->this_id, sizeof(state->this_id)); - kobject_uevent_env(&device->dev.kobj, KOBJ_CHANGE, envp); } static const struct acpi_device_id vmgenid_ids[] = { -- 2.44.0

12 months

6
15
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror