- Kernel - mailweb.openeuler.org

[openeuler:OLK-6.6 2195/2195] Documentation/devicetree/bindings/gpu/phytium,dc.yaml:40:8: [warning] wrong indentation: expected 2 but found 7 (indentation)
by kernel test robot 13 May '25

13 May '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 855c2a6945da5d74f3e50d601537000d0989d5a3 commit: ab9ff1e38569313e41ba5a036591f93cb55e5d87 [2195/2195] DRM: Phytium display DRM doc config: arm64-randconfig-2053-20250504 (https://download.01.org/0day-ci/archive/20250513/202505132302.zMQCF7g7-lkp@…) compiler: aarch64-linux-gcc (GCC) 9.5.0 dtschema version: 2025.3.dev21+ge6ea659 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250513/202505132302.zMQCF7g7-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202505132302.zMQCF7g7-lkp@intel.com/ dtcheck warnings: (new ones prefixed by >>) >> Documentation/devicetree/bindings/gpu/phytium,dc.yaml:40:8: [warning] wrong indentation: expected 2 but found 7 (indentation) Documentation/devicetree/bindings/arm/arm,mpam-msc.yaml:76:15: [error] string value is redundantly quoted with any quotes (quoted-strings) Documentation/devicetree/bindings/arm/arm,mpam-msc.yaml:82:15: [error] string value is redundantly quoted with any quotes (quoted-strings) -- >> Documentation/devicetree/bindings/gpu/phytium,dc.yaml: ignoring, error in schema: properties: clocks: items /usr/local/lib/python3.11/dist-packages/dtschema/schemas/reserved-memory/memory-region.yaml: warning: ignoring duplicate '$id' value 'http://devicetree.org/schemas/reserved-memory/memory-region.yaml#' /usr/local/lib/python3.11/dist-packages/dtschema/schemas/reserved-memory/framebuffer.yaml: warning: ignoring duplicate '$id' value 'http://devicetree.org/schemas/reserved-memory/framebuffer.yaml#' /usr/local/lib/python3.11/dist-packages/dtschema/schemas/reserved-memory/shared-dma-pool.yaml: warning: ignoring duplicate '$id' value 'http://devicetree.org/schemas/reserved-memory/shared-dma-pool.yaml#' /usr/local/lib/python3.11/dist-packages/dtschema/schemas/reserved-memory/reserved-memory.yaml: warning: ignoring duplicate '$id' value 'http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml#' Documentation/devicetree/bindings/sound/audio-graph-port.yaml: convert-sample-format: missing type definition Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml: i2c-alias: missing type definition Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml: dual-lvds-odd-pixels: missing type definition Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml: dual-lvds-even-pixels: missing type definition Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml: ti,x-plate-ohms: missing type definition Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml: input-debounce: multiple incompatible types: uint32-array vim +40 Documentation/devicetree/bindings/gpu/phytium,dc.yaml 33 34 required: 35 - compatible 36 - reg 37 - interrupts 38 39 Example: > 40 /memreserve/ 0xf4000000 0x4000000; // (optional) -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6 00/10] IPIV-BUGFIX for HIP12
by Jinqian Yang 13 May '25

13 May '25

Compared with the previous IPIV, the IPIV-BUGFIX has the following changes: 1. Use Kconfig to Control whether to enable IPIV. 2. Users use ioctl to control whether to enable IPIV. 3. Use the SMCCC interface for Guest OS to control whether to enable IPIV. 4. make sure vcpu_id == vcpu_idx. 5. the MPIDR cannot be changed When IPIV is enabled. 6. fix bug that ipiv enable is displayed on the host when "kvm-arm.vgic_v4_enable=0 kvm-arm.ipiv_enabled=1" is configured. 7. Add Exception Printing Patch#1 arm64/config: add config to control whether enable IPIV feature Patch#2 KVM: arm64: Introduce ipiv enable ioctl Patch#3 KVM: arm64: Document PV-sgi interface Patch#4 KVM: arm64: Implement PV_SGI related calls Patch#5 irqchip/gic: Add HiSilicon PV SGI support Patch#6 kvm: hisi: make sure vcpu_id and vcpu_idx have same value in IPIv Patch#7 kvm: hisi: Don't allow to change mpidr in IPIv Patch#8 KVM: arm64: using kvm_vgic_global_state for ipiv Patch#9 kvm: hisi: print error for IPIV Patch#10 arm64/kabi: use KABI_EXTEND to skip KABI check Jinqian Yang (4): arm64/config: add config to control whether enable IPIV feature KVM: arm64: using kvm_vgic_global_state for ipiv kvm: hisi: print error for IPIV arm64/kabi: use KABI_EXTEND to skip KABI check Zhou Wang (6): KVM: arm64: Introduce ipiv enable ioctl KVM: arm64: Document PV-sgi interface KVM: arm64: Implement PV_SGI related calls irqchip/gic: Add HiSilicon PV SGI support kvm: hisi: make sure vcpu_id and vcpu_idx have same value in IPIv kvm: hisi: Don't allow to change mpidr in IPIv Documentation/virt/kvm/arm/pvsgi.rst | 33 ++++++++++++++++ arch/arm64/Kconfig | 13 ++++++ arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/kvm_host.h | 3 ++ arch/arm64/kvm/arm.c | 34 ++++++++++++---- arch/arm64/kvm/hisilicon/hisi_virt.c | 25 +++++++++++- arch/arm64/kvm/hisilicon/hisi_virt.h | 20 ++++++++-- arch/arm64/kvm/hypercalls.c | 24 +++++++++++ arch/arm64/kvm/sys_regs.c | 34 +++++++++++----- arch/arm64/kvm/vgic/vgic-init.c | 42 +++++++++++++++++--- arch/arm64/kvm/vgic/vgic-mmio-v3.c | 2 + drivers/irqchip/irq-gic-v3-its.c | 50 ++++++++++++++++------- drivers/irqchip/irq-gic-v3.c | 55 ++++++++++++++++++++------ include/linux/arm-smccc.h | 15 +++++++ include/linux/irqchip/arm-gic-v3.h | 10 +++++ include/linux/irqchip/arm-gic-v4.h | 4 ++ 16 files changed, 311 insertions(+), 54 deletions(-) create mode 100644 Documentation/virt/kvm/arm/pvsgi.rst -- 2.33.0

2 12

[openeuler:OLK-6.6 2220/2220] kernel/sched/fair.c:7080:6: sparse: sparse: symbol 'free_affinity_domains' was not declared. Should it be static?
by kernel test robot 13 May '25

13 May '25

Hi Wang, First bad commit (maybe != root cause): tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 196f295c5eeefa026912137e7fc120f3c8565d2e commit: 1a553561230ab6bdc36f9e28e268c75b96dbe67e [2220/2220] sched: smart grid: init sched_grid_qos structure on QOS purpose config: x86_64-randconfig-123-20250513 (https://download.01.org/0day-ci/archive/20250513/202505132224.plUhY3K3-lkp@…) compiler: clang version 20.1.2 (https://github.com/llvm/llvm-project 58df0ef89dd64126512e4ee27b4ac3fd8ddf6247) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250513/202505132224.plUhY3K3-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202505132224.plUhY3K3-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) kernel/sched/fair.c:151:14: sparse: sparse: symbol 'sysctl_overload_detect_period' was not declared. Should it be static? kernel/sched/fair.c:152:14: sparse: sparse: symbol 'sysctl_offline_wait_interval' was not declared. Should it be static? kernel/sched/fair.c:164:14: sparse: sparse: symbol 'sysctl_sched_prio_load_balance_enabled' was not declared. Should it be static? kernel/sched/fair.c:209:5: sparse: sparse: symbol 'sysctl_sched_util_low_pct' was not declared. Should it be static? kernel/sched/fair.c:1310:34: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct sched_entity const *se @@ got struct sched_entity [noderef] __rcu * @@ kernel/sched/fair.c:1310:34: sparse: expected struct sched_entity const *se kernel/sched/fair.c:1310:34: sparse: got struct sched_entity [noderef] __rcu * kernel/sched/fair.c:13907:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:13907:9: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:13907:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:6071:22: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/fair.c:6071:22: sparse: struct task_struct [noderef] __rcu * kernel/sched/fair.c:6071:22: sparse: struct task_struct * >> kernel/sched/fair.c:7080:6: sparse: sparse: symbol 'free_affinity_domains' was not declared. Should it be static? kernel/sched/fair.c:7132:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] tmp @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:7132:9: sparse: expected struct sched_domain *[assigned] tmp kernel/sched/fair.c:7132:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:7146:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] tmp @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:7146:9: sparse: expected struct sched_domain *[assigned] tmp kernel/sched/fair.c:7146:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:7275:38: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct task_struct *curr @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:7275:38: sparse: expected struct task_struct *curr kernel/sched/fair.c:7275:38: sparse: got struct task_struct [noderef] __rcu *curr kernel/sched/fair.c:8658:20: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:8658:20: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:8658:20: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:9010:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] tmp @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:9010:9: sparse: expected struct sched_domain *[assigned] tmp kernel/sched/fair.c:9010:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:9122:38: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct task_struct *curr @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:9122:38: sparse: expected struct task_struct *curr kernel/sched/fair.c:9122:38: sparse: got struct task_struct [noderef] __rcu *curr kernel/sched/fair.c:9468:22: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/fair.c:9468:22: sparse: struct task_struct [noderef] __rcu * kernel/sched/fair.c:9468:22: sparse: struct task_struct * kernel/sched/fair.c:9553:1: sparse: sparse: symbol 'qos_smt_expell_switch' was not declared. Should it be static? kernel/sched/fair.c:9687:51: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct task_struct *sibling_p @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:9687:51: sparse: expected struct task_struct *sibling_p kernel/sched/fair.c:9687:51: sparse: got struct task_struct [noderef] __rcu *curr kernel/sched/fair.c:9692:30: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/fair.c:9692:30: sparse: struct task_struct [noderef] __rcu * kernel/sched/fair.c:9692:30: sparse: struct task_struct * kernel/sched/fair.c:9770:48: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct task_struct *p @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:10019:38: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct task_struct *curr @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:11107:40: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct sched_domain *child @@ got struct sched_domain [noderef] __rcu *child @@ kernel/sched/fair.c:11744:22: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/fair.c:11744:22: sparse: struct task_struct [noderef] __rcu * kernel/sched/fair.c:11744:22: sparse: struct task_struct * kernel/sched/fair.c:13185:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:13185:9: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:13185:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:12842:44: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct sched_domain *sd_parent @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:12842:44: sparse: expected struct sched_domain *sd_parent kernel/sched/fair.c:12842:44: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:13281:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:13281:9: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:13281:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c: note: in included file: kernel/sched/sched.h:2244:25: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2244:25: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2244:25: sparse: struct task_struct * kernel/sched/sched.h:2408:9: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2408:9: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2408:9: sparse: struct task_struct * kernel/sched/sched.h:2408:9: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2408:9: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2408:9: sparse: struct task_struct * kernel/sched/sched.h:2244:25: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2244:25: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2244:25: sparse: struct task_struct * kernel/sched/sched.h:2244:25: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2244:25: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2244:25: sparse: struct task_struct * vim +/free_affinity_domains +7080 kernel/sched/fair.c 6eb07f9925a906 Hui Tang 2024-01-17 7079 6eb07f9925a906 Hui Tang 2024-01-17 @7080 void free_affinity_domains(struct affinity_domain *ad) 6eb07f9925a906 Hui Tang 2024-01-17 7081 { 6eb07f9925a906 Hui Tang 2024-01-17 7082 int i; 6eb07f9925a906 Hui Tang 2024-01-17 7083 6eb07f9925a906 Hui Tang 2024-01-17 7084 for (i = 0; i < AD_LEVEL_MAX; i++) { 6eb07f9925a906 Hui Tang 2024-01-17 7085 kfree(ad->domains[i]); 6eb07f9925a906 Hui Tang 2024-01-17 7086 kfree(ad->domains_orig[i]); 6eb07f9925a906 Hui Tang 2024-01-17 7087 ad->domains[i] = NULL; 6eb07f9925a906 Hui Tang 2024-01-17 7088 ad->domains_orig[i] = NULL; 6eb07f9925a906 Hui Tang 2024-01-17 7089 } 6eb07f9925a906 Hui Tang 2024-01-17 7090 ad->dcount = 0; 6eb07f9925a906 Hui Tang 2024-01-17 7091 } 6eb07f9925a906 Hui Tang 2024-01-17 7092 :::::: The code at line 7080 was first introduced by commit :::::: 6eb07f9925a906d81f328c808ba25f7800888dce sched: Introduce smart grid scheduling strategy for cfs :::::: TO: Hui Tang <tanghui20(a)huawei.com> :::::: CC: yanhaitao <yanhaitao2(a)huawei.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[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: https://gitee.com/openeuler/kernel/issues/IC7KK7 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 0/7] arm64: Add support for FEAT_{LS64, LS64_V}
by Yushan Wang 13 May '25

13 May '25

From: Hongye Lin <linhongye(a)h-partners.com> 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 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

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-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