- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] kvm: x86: fix infinite loop in kvm_guest_time_update when tsc is 0
by Yuntao Liu 13 May '25

13 May '25

hulk inclusion category: bugfix bugzilla: 190614 CVE: NA -------------------------------- Fixes: 35181e86df97 ("KVM: x86: Add a common TSC scaling function") Syzkaller testing detected a soft lockup. watchdog: BUG: soft lockup - CPU#3 stuck for 127s! [syz.1.2088:9817] Modules linked in: CPU: 3 PID: 9817 Comm: syz.1.2088 Tainted: G S 6.6.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x8/0x20 kernel/kcov.c:313 Code: bf 03 00 00 00 e9 48 fe ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 8b 0c 24 <89> f2 89 fe bf 05 00 00 00 e9 1a fe ff ff 66 2e 0f 1f 84 00 00 00 RSP: 0018:ffff888016d8fad8 EFLAGS: 00000206 RAX: 0000000000080000 RBX: ffff88810e242540 RCX: ffffffff901150d6 RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888016d8fb50 R08: 0000000000000001 R09: ffffed1021c484af R10: 0000000000000000 R11: 0000000000000277 R12: 0000000000000000 R13: fffffed357281918 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f2a8f6ea6c0(0000) GS:ffff888119780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000012c56c0 CR3: 000000000dce8001 CR4: 0000000000772ee0 DR0: 0000000000000000 DR1: 0000000000d3eb1c DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline] kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268 vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678 vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126 kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352 kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ioctl$KVM_SET_TSC_KHZ(r2, 0xaea2, 0x1) user_tsc_khz = 0x1 | kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz) | ioctl$KVM_RUN(r2, 0xae80, 0x0) | ... kvm_guest_time_update(struct kvm_vcpu *v) | if (kvm_caps.has_tsc_control) tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz, v->arch.l1_tsc_scaling_ratio); | kvm_scale_tsc(u64 tsc, u64 ratio) | __scale_tsc(u64 ratio, u64 tsc) ratio=122380531, tsc=2299998, N=48 ratio*tsc >> N = 0.999... -> 0 | kvm_get_time_scale In function __scale_tsc, it uses fixed point number to calculate tsc, therefore, a certain degree of precision is lost, the actual tsc value of 0.999... would be 0. In function kvm_get_time_scale tps32=tps64=base_hz=0, would lead second while_loop infinite. when CONFIG_PREEMPT is n, it causes a soft lockup issue. Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index d2d206ff6462..dec2d3baf202 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2428,10 +2428,14 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu) * point number (mult + frac * 2^(-N)). * * N equals to kvm_tsc_scaling_ratio_frac_bits. + * + * return 1 if _tsc is 0. */ static inline u64 __scale_tsc(u64 ratio, u64 tsc) { - return mul_u64_u64_shr(tsc, ratio, kvm_tsc_scaling_ratio_frac_bits); + u64 _tsc = mul_u64_u64_shr(tsc, ratio, kvm_tsc_scaling_ratio_frac_bits); + + return !_tsc ? 1 : _tsc; } u64 kvm_scale_tsc(struct kvm_vcpu *vcpu, u64 tsc) -- 2.34.1

2 1

[PATCH OLK-6.6] kvm: x86: fix infinite loop in kvm_guest_time_update when tsc is 0
by Yuntao Liu 13 May '25

13 May '25

hulk inclusion category: bugfix bugzilla: 190614 CVE: NA -------------------------------- Fixes: 35181e86df97 ("KVM: x86: Add a common TSC scaling function") Syzkaller testing detected a soft lockup. watchdog: BUG: soft lockup - CPU#3 stuck for 127s! [syz.1.2088:9817] Modules linked in: CPU: 3 PID: 9817 Comm: syz.1.2088 Tainted: G S 6.6.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x8/0x20 kernel/kcov.c:313 Code: bf 03 00 00 00 e9 48 fe ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 8b 0c 24 <89> f2 89 fe bf 05 00 00 00 e9 1a fe ff ff 66 2e 0f 1f 84 00 00 00 RSP: 0018:ffff888016d8fad8 EFLAGS: 00000206 RAX: 0000000000080000 RBX: ffff88810e242540 RCX: ffffffff901150d6 RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888016d8fb50 R08: 0000000000000001 R09: ffffed1021c484af R10: 0000000000000000 R11: 0000000000000277 R12: 0000000000000000 R13: fffffed357281918 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f2a8f6ea6c0(0000) GS:ffff888119780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000012c56c0 CR3: 000000000dce8001 CR4: 0000000000772ee0 DR0: 0000000000000000 DR1: 0000000000d3eb1c DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline] kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268 vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678 vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126 kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352 kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ioctl$KVM_SET_TSC_KHZ(r2, 0xaea2, 0x1) user_tsc_khz = 0x1 | kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz) | ioctl$KVM_RUN(r2, 0xae80, 0x0) | ... kvm_guest_time_update(struct kvm_vcpu *v) | if (kvm_caps.has_tsc_control) tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz, v->arch.l1_tsc_scaling_ratio); | kvm_scale_tsc(u64 tsc, u64 ratio) | __scale_tsc(u64 ratio, u64 tsc) ratio=122380531, tsc=2299998, N=48 ratio*tsc >> N = 0.999... -> 0 | kvm_get_time_scale In function __scale_tsc, it uses fixed point number to calculate tsc, therefore, a certain degree of precision is lost, the actual tsc value of 0.999... would be 0. In function kvm_get_time_scale tps32=tps64=base_hz=0, would lead second while_loop infinite. when CONFIG_PREEMPT is n, it causes a soft lockup issue. Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 1fa5d89f8d27..3e9d6f368eed 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2605,10 +2605,14 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu) * point number (mult + frac * 2^(-N)). * * N equals to kvm_caps.tsc_scaling_ratio_frac_bits. + * + * return 1 if _tsc is 0. */ static inline u64 __scale_tsc(u64 ratio, u64 tsc) { - return mul_u64_u64_shr(tsc, ratio, kvm_caps.tsc_scaling_ratio_frac_bits); + u64 _tsc = mul_u64_u64_shr(tsc, ratio, kvm_caps.tsc_scaling_ratio_frac_bits); + + return !_tsc ? 1 : _tsc; } u64 kvm_scale_tsc(u64 tsc, u64 ratio) -- 2.34.1

2 1

[PATCH OLK-6.6] kvm: x86: fix infinite loop in kvm_guest_time_update when tsc is 0
by Yuntao Liu 13 May '25

13 May '25

Offering: HULK hulk inclusion category: bugfix bugzilla: 190614 CVE: NA -------------------------------- Fixes: 35181e86df97 ("KVM: x86: Add a common TSC scaling function") Syzkaller testing detected a soft lockup. watchdog: BUG: soft lockup - CPU#3 stuck for 127s! [syz.1.2088:9817] Modules linked in: CPU: 3 PID: 9817 Comm: syz.1.2088 Tainted: G S 6.6.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x8/0x20 kernel/kcov.c:313 Code: bf 03 00 00 00 e9 48 fe ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 8b 0c 24 <89> f2 89 fe bf 05 00 00 00 e9 1a fe ff ff 66 2e 0f 1f 84 00 00 00 RSP: 0018:ffff888016d8fad8 EFLAGS: 00000206 RAX: 0000000000080000 RBX: ffff88810e242540 RCX: ffffffff901150d6 RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888016d8fb50 R08: 0000000000000001 R09: ffffed1021c484af R10: 0000000000000000 R11: 0000000000000277 R12: 0000000000000000 R13: fffffed357281918 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f2a8f6ea6c0(0000) GS:ffff888119780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000012c56c0 CR3: 000000000dce8001 CR4: 0000000000772ee0 DR0: 0000000000000000 DR1: 0000000000d3eb1c DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline] kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268 vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678 vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126 kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352 kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ioctl$KVM_SET_TSC_KHZ(r2, 0xaea2, 0x1) user_tsc_khz = 0x1 | kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz) | ioctl$KVM_RUN(r2, 0xae80, 0x0) | ... kvm_guest_time_update(struct kvm_vcpu *v) | if (kvm_caps.has_tsc_control) tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz, v->arch.l1_tsc_scaling_ratio); | kvm_scale_tsc(u64 tsc, u64 ratio) | __scale_tsc(u64 ratio, u64 tsc) ratio=122380531, tsc=2299998, N=48 ratio*tsc >> N = 0.999... -> 0 | kvm_get_time_scale In function __scale_tsc, it uses fixed point number to calculate tsc, therefore, a certain degree of precision is lost, the actual tsc value of 0.999... would be 0. In function kvm_get_time_scale tps32=tps64=base_hz=0, would lead second while_loop infinite. when CONFIG_PREEMPT is n, it causes a soft lockup issue. Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 1fa5d89f8d27..3e9d6f368eed 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2605,10 +2605,14 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu) * point number (mult + frac * 2^(-N)). * * N equals to kvm_caps.tsc_scaling_ratio_frac_bits. + * + * return 1 if _tsc is 0. */ static inline u64 __scale_tsc(u64 ratio, u64 tsc) { - return mul_u64_u64_shr(tsc, ratio, kvm_caps.tsc_scaling_ratio_frac_bits); + u64 _tsc = mul_u64_u64_shr(tsc, ratio, kvm_caps.tsc_scaling_ratio_frac_bits); + + return !_tsc ? 1 : _tsc; } u64 kvm_scale_tsc(u64 tsc, u64 ratio) -- 2.34.1

2 1

[PATCH OLK-6.6] kvm: x86: fix infinite loop in kvm_guest_time_update when tsc is 0
by Yuntao Liu 13 May '25

13 May '25

Offering: HULK hulk inclusion category: bugfix bugzilla: 190614 CVE: NA -------------------------------- Fixes: 35181e86df97 ("KVM: x86: Add a common TSC scaling function") Syzkaller testing detected a soft lockup. watchdog: BUG: soft lockup - CPU#3 stuck for 127s! [syz.1.2088:9817] Modules linked in: CPU: 3 PID: 9817 Comm: syz.1.2088 Tainted: G S 6.6.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x8/0x20 kernel/kcov.c:313 Code: bf 03 00 00 00 e9 48 fe ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 8b 0c 24 <89> f2 89 fe bf 05 00 00 00 e9 1a fe ff ff 66 2e 0f 1f 84 00 00 00 RSP: 0018:ffff888016d8fad8 EFLAGS: 00000206 RAX: 0000000000080000 RBX: ffff88810e242540 RCX: ffffffff901150d6 RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888016d8fb50 R08: 0000000000000001 R09: ffffed1021c484af R10: 0000000000000000 R11: 0000000000000277 R12: 0000000000000000 R13: fffffed357281918 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f2a8f6ea6c0(0000) GS:ffff888119780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000012c56c0 CR3: 000000000dce8001 CR4: 0000000000772ee0 DR0: 0000000000000000 DR1: 0000000000d3eb1c DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline] kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268 vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678 vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126 kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352 kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ioctl$KVM_SET_TSC_KHZ(r2, 0xaea2, 0x1) user_tsc_khz = 0x1 | kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz) | ioctl$KVM_RUN(r2, 0xae80, 0x0) | ... kvm_guest_time_update(struct kvm_vcpu *v) | if (kvm_caps.has_tsc_control) tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz, v->arch.l1_tsc_scaling_ratio); | kvm_scale_tsc(u64 tsc, u64 ratio) | __scale_tsc(u64 ratio, u64 tsc) ratio=122380531, tsc=2299998, N=48 ratio*tsc >> N = 0.999... -> 0 | kvm_get_time_scale In function __scale_tsc, it uses fixed point number to calculate tsc, therefore, a certain degree of precision is lost, the actual tsc value of 0.999... would be 0. In function kvm_get_time_scale tps32=tps64=base_hz=0, would lead second while_loop infinite. when CONFIG_PREEMPT is n, it causes a soft lockup issue. Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 1fa5d89f8d27..57a12f2a4642 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2605,10 +2605,14 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu) * point number (mult + frac * 2^(-N)). * * N equals to kvm_caps.tsc_scaling_ratio_frac_bits. + * + * return 1 if _tsc is 0. */ static inline u64 __scale_tsc(u64 ratio, u64 tsc) { - return mul_u64_u64_shr(tsc, ratio, kvm_caps.tsc_scaling_ratio_frac_bits); + u64 _tsc = mul_u64_u64_shr(tsc, ratio, kvm_caps.tsc_scaling_ratio_frac_bits); + + return !_tsc ? 1 : _tsc; } u64 kvm_scale_tsc(u64 tsc, u64 ratio) -- 2.34.1

2 1

[PATCH OLK-5.10] kvm: x86: fix infinite loop in kvm_guest_time_update when tsc is 0
by Yuntao Liu 13 May '25

13 May '25

Offering: HULK hulk inclusion category: bugfix bugzilla: 190614 CVE: NA -------------------------------- Fixes: 35181e86df97 ("KVM: x86: Add a common TSC scaling function") Syzkaller testing detected a soft lockup. watchdog: BUG: soft lockup - CPU#3 stuck for 127s! [syz.1.2088:9817] Modules linked in: CPU: 3 PID: 9817 Comm: syz.1.2088 Tainted: G S 6.6.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x8/0x20 kernel/kcov.c:313 Code: bf 03 00 00 00 e9 48 fe ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 8b 0c 24 <89> f2 89 fe bf 05 00 00 00 e9 1a fe ff ff 66 2e 0f 1f 84 00 00 00 RSP: 0018:ffff888016d8fad8 EFLAGS: 00000206 RAX: 0000000000080000 RBX: ffff88810e242540 RCX: ffffffff901150d6 RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888016d8fb50 R08: 0000000000000001 R09: ffffed1021c484af R10: 0000000000000000 R11: 0000000000000277 R12: 0000000000000000 R13: fffffed357281918 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f2a8f6ea6c0(0000) GS:ffff888119780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000012c56c0 CR3: 000000000dce8001 CR4: 0000000000772ee0 DR0: 0000000000000000 DR1: 0000000000d3eb1c DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline] kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268 vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678 vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126 kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352 kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ioctl$KVM_SET_TSC_KHZ(r2, 0xaea2, 0x1) user_tsc_khz = 0x1 | kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz) | ioctl$KVM_RUN(r2, 0xae80, 0x0) | ... kvm_guest_time_update(struct kvm_vcpu *v) | if (kvm_caps.has_tsc_control) tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz, v->arch.l1_tsc_scaling_ratio); | kvm_scale_tsc(u64 tsc, u64 ratio) | __scale_tsc(u64 ratio, u64 tsc) ratio=122380531, tsc=2299998, N=48 ratio*tsc >> N = 0.999... -> 0 | kvm_get_time_scale In function __scale_tsc, it uses fixed point number to calculate tsc, therefore, a certain degree of precision is lost, the actual tsc value of 0.999... would be 0. In function kvm_get_time_scale tps32=tps64=base_hz=0, would lead second while_loop infinite. when CONFIG_PREEMPT is n, it causes a soft lockup issue. Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index d2d206ff6462..dec2d3baf202 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2428,10 +2428,14 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu) * point number (mult + frac * 2^(-N)). * * N equals to kvm_tsc_scaling_ratio_frac_bits. + * + * return 1 if _tsc is 0. */ static inline u64 __scale_tsc(u64 ratio, u64 tsc) { - return mul_u64_u64_shr(tsc, ratio, kvm_tsc_scaling_ratio_frac_bits); + u64 _tsc = mul_u64_u64_shr(tsc, ratio, kvm_tsc_scaling_ratio_frac_bits); + + return !_tsc ? 1 : _tsc; } u64 kvm_scale_tsc(struct kvm_vcpu *vcpu, u64 tsc) -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] kvm: x86: fix infinite loop in kvm_guest_time_update when tsc is 0
by Yuntao Liu 13 May '25

13 May '25

Offering: HULK hulk inclusion category: bugfix bugzilla: 190614 CVE: NA -------------------------------- Fixes: 35181e86df97 ("KVM: x86: Add a common TSC scaling function") Syzkaller testing detected a soft lockup. watchdog: BUG: soft lockup - CPU#3 stuck for 127s! [syz.1.2088:9817] Modules linked in: CPU: 3 PID: 9817 Comm: syz.1.2088 Tainted: G S 6.6.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x8/0x20 kernel/kcov.c:313 Code: bf 03 00 00 00 e9 48 fe ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 8b 0c 24 <89> f2 89 fe bf 05 00 00 00 e9 1a fe ff ff 66 2e 0f 1f 84 00 00 00 RSP: 0018:ffff888016d8fad8 EFLAGS: 00000206 RAX: 0000000000080000 RBX: ffff88810e242540 RCX: ffffffff901150d6 RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888016d8fb50 R08: 0000000000000001 R09: ffffed1021c484af R10: 0000000000000000 R11: 0000000000000277 R12: 0000000000000000 R13: fffffed357281918 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f2a8f6ea6c0(0000) GS:ffff888119780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000012c56c0 CR3: 000000000dce8001 CR4: 0000000000772ee0 DR0: 0000000000000000 DR1: 0000000000d3eb1c DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline] kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268 vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678 vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126 kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352 kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ioctl$KVM_SET_TSC_KHZ(r2, 0xaea2, 0x1) user_tsc_khz = 0x1 | kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz) | ioctl$KVM_RUN(r2, 0xae80, 0x0) | ... kvm_guest_time_update(struct kvm_vcpu *v) | if (kvm_caps.has_tsc_control) tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz, v->arch.l1_tsc_scaling_ratio); | kvm_scale_tsc(u64 tsc, u64 ratio) | __scale_tsc(u64 ratio, u64 tsc) ratio=122380531, tsc=2299998, N=48 ratio*tsc >> N = 0.999... -> 0 | kvm_get_time_scale In function __scale_tsc, it uses fixed point number to calculate tsc, therefore, a certain degree of precision is lost, the actual tsc value of 0.999... would be 0. In function kvm_get_time_scale tps32=tps64=base_hz=0, would lead second while_loop infinite. when CONFIG_PREEMPT is n, it causes a soft lockup issue. Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 6afffdcc656e..83d215d43eb3 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1673,10 +1673,14 @@ static void update_ia32_tsc_adjust_msr(struct kvm_vcpu *vcpu, s64 offset) * point number (mult + frac * 2^(-N)). * * N equals to kvm_tsc_scaling_ratio_frac_bits. + * + * return 1 if _tsc is 0. */ static inline u64 __scale_tsc(u64 ratio, u64 tsc) { - return mul_u64_u64_shr(tsc, ratio, kvm_tsc_scaling_ratio_frac_bits); + u64 _tsc = mul_u64_u64_shr(tsc, ratio, kvm_tsc_scaling_ratio_frac_bits); + + return !_tsc ? 1 : _tsc; } u64 kvm_scale_tsc(struct kvm_vcpu *vcpu, u64 tsc) -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] Update the watchdog period according to real CPU frequency
by Qinxin Xia 13 May '25

13 May '25

driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IC7CQP ---------------------------------------------------------------------- watchdog perf needs architecture to provide method for converting the watchdog thresh to counter period. For arm64 we're using the max CPU frequency for doing the conversion which is from cpufreq driver. But some cpufreq driver are registered lately, for example cppc_cpufreq will be registered at late initcall which is after the initialization of watchdog perf (initialized in armv8_pmuv3 of device initcall). In such case the period of watchdog will not be accurate enough. Fix this by registering a cpufreq notifier and update the watchdog period once the cpufreq driver is initialized. Yicong Yang (2): watchdog/perf: Provide function for adjusting the event period arm64/watchdog_hld: Add a cpufreq notifier for update watchdog thresh arch/arm64/kernel/watchdog_hld.c | 58 ++++++++++++++++++++++++++++++++ include/linux/nmi.h | 2 ++ kernel/watchdog_perf.c | 23 +++++++++++++ 3 files changed, 83 insertions(+) -- 2.33.0

2 3

[PATCH OLK-6.6 0/7] arm64: Add support for FEAT_{LS64, LS64_V}
by Qinxin Xia 13 May '25

13 May '25

driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IC76OZ ---------------------------------------------------------------------- Armv8.7 introduces single-copy atomic 64-byte loads and stores instructions and its variants named under FEAT_{LS64, LS64_V}. These features are identified by ID_AA64ISAR1_EL1.LS64 and the use of such instructions in userspace (EL0) can be trapped. In order to support the use of corresponding instructions in userspace: Make ID_AA64ISAR1_EL1.LS64 visbile to userspace Add identifying and enabling in the cpufeature list Expose these support of these features to userspace through HWCAP3 and cpuinfo Mark Brown (2): arm64: Support AT_HWCAP3 binfmt_elf: Wire up AT_HWCAP3 at AT_HWCAP4 Peter Bergner (1): uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries Yicong Yang (4): arm64: Provide basic EL2 setup for FEAT_{LS64, LS64_V} usage at EL0/1 arm64: Add support for FEAT_{LS64, LS64_V} Workaround the issue when compile with CONFIG_FUNCTION_ALIGNMENT_64B KVM: arm64: Enable FEAT_{LS64, LS64_V} in the supported guest Documentation/arch/arm64/booting.rst | 12 +++++ Documentation/arch/arm64/elf_hwcaps.rst | 12 +++-- arch/arm64/Kconfig | 4 ++ arch/arm64/include/asm/cpufeature.h | 3 +- arch/arm64/include/asm/el2_setup.h | 13 ++++++ arch/arm64/include/asm/hwcap.h | 7 ++- arch/arm64/include/uapi/asm/hwcap.h | 6 +++ arch/arm64/kernel/cpufeature.c | 61 +++++++++++++++++++++++++ arch/arm64/kernel/cpuinfo.c | 2 + arch/arm64/kvm/hyp/include/hyp/switch.h | 6 +++ arch/arm64/tools/cpucaps | 4 +- fs/binfmt_elf.c | 6 +++ fs/binfmt_elf_fdpic.c | 6 +++ fs/compat_binfmt_elf.c | 10 ++++ include/uapi/linux/auxvec.h | 2 + 15 files changed, 147 insertions(+), 7 deletions(-) -- 2.33.0

2 8

[PATCH OLK-6.6 0/7] arm64: Add support for FEAT_{LS64, LS64_V}
by Qinxin Xia 13 May '25

13 May '25

driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IC76OZ ---------------------------------------------------------------------- Armv8.7 introduces single-copy atomic 64-byte loads and stores instructions and its variants named under FEAT_{LS64, LS64_V}. These features are identified by ID_AA64ISAR1_EL1.LS64 and the use of such instructions in userspace (EL0) can be trapped. In order to support the use of corresponding instructions in userspace: Make ID_AA64ISAR1_EL1.LS64 visbile to userspace Add identifying and enabling in the cpufeature list Expose these support of these features to userspace through HWCAP3 and cpuinfo Mark Brown (2): arm64: Support AT_HWCAP3 binfmt_elf: Wire up AT_HWCAP3 at AT_HWCAP4 Peter Bergner (1): uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries Yicong Yang (4): arm64: Provide basic EL2 setup for FEAT_{LS64, LS64_V} usage at EL0/1 arm64: Add support for FEAT_{LS64, LS64_V} Workaround the issue when compile with CONFIG_FUNCTION_ALIGNMENT_64B KVM: arm64: Enable FEAT_{LS64, LS64_V} in the supported guest Documentation/arch/arm64/booting.rst | 12 +++++ Documentation/arch/arm64/elf_hwcaps.rst | 12 +++-- arch/arm64/Kconfig | 4 ++ arch/arm64/include/asm/cpufeature.h | 3 +- arch/arm64/include/asm/el2_setup.h | 13 ++++++ arch/arm64/include/asm/hwcap.h | 7 ++- arch/arm64/include/uapi/asm/hwcap.h | 6 +++ arch/arm64/kernel/cpufeature.c | 61 +++++++++++++++++++++++++ arch/arm64/kernel/cpuinfo.c | 2 + arch/arm64/kvm/hyp/include/hyp/switch.h | 6 +++ arch/arm64/tools/cpucaps | 4 +- fs/binfmt_elf.c | 6 +++ fs/binfmt_elf_fdpic.c | 6 +++ fs/compat_binfmt_elf.c | 10 ++++ include/uapi/linux/auxvec.h | 2 + 15 files changed, 147 insertions(+), 7 deletions(-) -- 2.33.0

2 8

[PATCH OLK-6.6 0/2] Update the watchdog period according to real CPU frequency
by Qinxin Xia 13 May '25

13 May '25

driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IC7CQP ---------------------------------------------------------------------- watchdog perf needs architecture to provide method for converting the watchdog thresh to counter period. For arm64 we're using the max CPU frequency for doing the conversion which is from cpufreq driver. But some cpufreq driver are registered lately, for example cppc_cpufreq will be registered at late initcall which is after the initialization of watchdog perf (initialized in armv8_pmuv3 of device initcall). In such case the period of watchdog will not be accurate enough. Fix this by registering a cpufreq notifier and update the watchdog period once the cpufreq driver is initialized. Yicong Yang (2): watchdog/perf: Provide function for adjusting the event period arm64/watchdog_hld: Add a cpufreq notifier for update watchdog thresh arch/arm64/kernel/watchdog_hld.c | 58 ++++++++++++++++++++++++++++++++ include/linux/nmi.h | 2 ++ kernel/watchdog_perf.c | 23 +++++++++++++ 3 files changed, 83 insertions(+) -- 2.33.0

2 3