- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] blk-mq: use quiesced elevator switch when reinitializing queues
by Zizhi Wo 20 Oct '25

20 Oct '25

From: Keith Busch <kbusch(a)kernel.org> stable inclusion from stable-v5.19.17 commit 63a681bcc32a43528ce0f690569f7f48e59c3963 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID0VGQ CVE: CVE-2022-50552 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8237c01f1696bc53c470493bf1fe092a107648a6 ] The hctx's run_work may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally. nvme nvme0: resetting controller nvme nvme0: 32/0/0 default/read/poll queues BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:kyber_has_work+0x29/0x70 ... Call Trace: __blk_mq_do_dispatch_sched+0x83/0x2b0 __blk_mq_sched_dispatch_requests+0x12e/0x170 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x2b/0x50 process_one_work+0x1ef/0x380 worker_thread+0x2d/0x3e0 Signed-off-by: Keith Busch <kbusch(a)kernel.org> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Link: https://lore.kernel.org/r/20220927155652.3260724-1-kbusch@fb.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: block/blk-mq.c block/blk.h block/elevator.c [Simple context conflicts do not affect this patch.] Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- block/blk-mq.c | 6 +++--- block/blk.h | 3 +-- block/elevator.c | 4 ++-- 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/block/blk-mq.c b/block/blk-mq.c index e1253b18516b..926eaf19d9d6 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -3277,14 +3277,14 @@ static bool blk_mq_elv_switch_none(struct list_head *head, mutex_lock(&q->sysfs_lock); /* - * After elevator_switch_mq, the previous elevator_queue will be + * After elevator_switch, the previous elevator_queue will be * released by elevator_release. The reference of the io scheduler * module get by elevator_get will also be put. So we need to get * a reference of the io scheduler module here to prevent it to be * removed. */ __module_get(qe->type->elevator_owner); - elevator_switch_mq(q, NULL); + elevator_switch(q, NULL); mutex_unlock(&q->sysfs_lock); return true; @@ -3309,7 +3309,7 @@ static void blk_mq_elv_switch_back(struct list_head *head, kfree(qe); mutex_lock(&q->sysfs_lock); - elevator_switch_mq(q, t); + elevator_switch(q, t); mutex_unlock(&q->sysfs_lock); } diff --git a/block/blk.h b/block/blk.h index 2730b239f158..cf7f26013b44 100644 --- a/block/blk.h +++ b/block/blk.h @@ -319,8 +319,7 @@ static inline void elv_deactivate_rq(struct request_queue *q, struct request *rq int elevator_init(struct request_queue *); int elevator_init_mq(struct request_queue *q); -int elevator_switch_mq(struct request_queue *q, - struct elevator_type *new_e); +int elevator_switch(struct request_queue *q, struct elevator_type *new_e); void elevator_exit(struct request_queue *, struct elevator_queue *); int elv_register_queue(struct request_queue *q, bool uevent); void elv_unregister_queue(struct request_queue *q); diff --git a/block/elevator.c b/block/elevator.c index 91c8769882d5..bee497c324eb 100644 --- a/block/elevator.c +++ b/block/elevator.c @@ -941,7 +941,7 @@ void elv_unregister(struct elevator_type *e) } EXPORT_SYMBOL_GPL(elv_unregister); -int elevator_switch_mq(struct request_queue *q, +static int elevator_switch_mq(struct request_queue *q, struct elevator_type *new_e) { int ret; @@ -1013,7 +1013,7 @@ int elevator_init_mq(struct request_queue *q) * need for the new one. this way we have a chance of going back to the old * one, if the new one fails init for some reason. */ -static int elevator_switch(struct request_queue *q, struct elevator_type *new_e) +int elevator_switch(struct request_queue *q, struct elevator_type *new_e) { struct elevator_queue *old = q->elevator; bool old_registered = false; -- 2.39.2

2 1

[PATCH OLK-6.6 0/2] arm64/mpam: Fix MBWU monitor overflow handling
by Zeng Heng 20 Oct '25

20 Oct '25

Zeng Heng (2): arm64/mpam: Fix MBWU monitor overflow handling arm64/mpam: Print MPAM register operation for debug drivers/platform/mpam/mpam_devices.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6] fs/resctrl: Re-allocate rmid for the monitor when migrating across control groups
by Zeng Heng 20 Oct '25

20 Oct '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ID29XA -------------------------------- On x86 RDT, RMIDs are completely independent of CLOSIDs, so a monitor group can move between control groups freely without modifying rmid_entry. On ARM64 MPAM, however, a CLOSID owns a slice of RMID space. When migrate the monitor group to another control group, it should therefore re-allocate for a RMID tied to the new CLOSID. If the migrated monitor keeps the old CLOSID, tasks of the monitor will still adopt the previous CLOSID's settings and when the monitor group is later destroyed, the same rmid_entry will be added to the rmid_free_lru list twice, which corrupting the list. Fixes: 8da2b938eb7e ("x86/resctrl: Implement rename op for mon groups") Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- fs/resctrl/internal.h | 1 + fs/resctrl/monitor.c | 2 +- fs/resctrl/rdtgroup.c | 10 ++++++++++ 3 files changed, 12 insertions(+), 1 deletion(-) diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h index 839fbcf51ed2..0e8865bf012a 100644 --- a/fs/resctrl/internal.h +++ b/fs/resctrl/internal.h @@ -294,5 +294,6 @@ bool has_busy_rmid(struct rdt_domain *d); void __check_limbo(struct rdt_domain *d, bool force_free); void rdt_staged_configs_clear(void); int resctrl_find_cleanest_closid(void); +struct rmid_entry *resctrl_find_free_rmid(u32 closid); #endif /* _FS_RESCTRL_INTERNAL_H */ diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c index d10497013638..b651b37e7e65 100644 --- a/fs/resctrl/monitor.c +++ b/fs/resctrl/monitor.c @@ -178,7 +178,7 @@ bool has_busy_rmid(struct rdt_domain *d) return find_first_bit(d->rmid_busy_llc, idx_limit) != idx_limit; } -static struct rmid_entry *resctrl_find_free_rmid(u32 closid) +struct rmid_entry *resctrl_find_free_rmid(u32 closid) { struct rmid_entry *itr; u32 itr_idx, cmp_idx; diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c index 091dc20d0cc0..3d3b12db69b4 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -3813,6 +3813,8 @@ static void mongrp_reparent(struct rdtgroup *rdtgrp, list_move_tail(&rdtgrp->mon.crdtgrp_list, &new_prdtgrp->mon.crdtgrp_list); + free_rmid(rdtgrp->closid, rdtgrp->mon.rmid); + rdtgrp->mon.rmid = alloc_rmid(new_prdtgrp->closid); rdtgrp->mon.parent = new_prdtgrp; rdtgrp->closid = new_prdtgrp->closid; @@ -3826,6 +3828,7 @@ static int rdtgroup_rename(struct kernfs_node *kn, struct kernfs_node *new_parent, const char *new_name) { struct rdtgroup *new_prdtgrp; + struct rmid_entry *entry; struct rdtgroup *rdtgrp; cpumask_var_t tmpmask; int ret; @@ -3884,6 +3887,13 @@ static int rdtgroup_rename(struct kernfs_node *kn, goto out; } + entry = resctrl_find_free_rmid(new_prdtgrp->closid); + if (IS_ERR(entry)) { + rdt_last_cmd_puts("Destination has been out of RMIDs\n"); + ret = PTR_ERR(entry); + goto out; + } + /* * Allocate the cpumask for use in mongrp_reparent() to avoid the * possibility of failing to allocate it after kernfs_rename() has -- 2.25.1

2 1

[PATCH OLK-6.6] arm64: add cnp verification on Hisilicon erratum 162100125
by Jinqian Yang 20 Oct '25

20 Oct '25

From: yangjinqian <yangjinqian1(a)huawei.com> virt inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IBN3WI ------------------------------------------------------------------------ When errata 162100125 matches, only the MIDR value is checked to see if the CPU matches. It is also important to check whether the CnP in the MMFR2 register is enabled. If CnP is not enabled, this errata is not required. Signed-off-by: Jinqian Yang <yangjinqian1(a)huawei.com> Signed-off-by: Zhou Wang <wangzhou1(a)hisilicon.com> --- arch/arm64/include/asm/cpufeature.h | 14 ++++++++++++++ arch/arm64/kernel/cpu_errata.c | 13 ++++++++++++- 2 files changed, 26 insertions(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h index c4d4ab854e81..6f73a51d2422 100644 --- a/arch/arm64/include/asm/cpufeature.h +++ b/arch/arm64/include/asm/cpufeature.h @@ -652,6 +652,20 @@ static inline bool cpu_supports_mixed_endian_el0(void) return id_aa64mmfr0_mixed_endian_el0(read_cpuid(ID_AA64MMFR0_EL1)); } +static inline bool supports_cnp(int scope) +{ + u64 mmfr2; + u8 cnp; + + if (scope == SCOPE_LOCAL_CPU) + mmfr2 = read_sysreg_s(SYS_ID_AA64MMFR2_EL1); + else + mmfr2 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR2_EL1); + + cnp = cpuid_feature_extract_unsigned_field(mmfr2, + ID_AA64MMFR2_EL1_CnP_SHIFT); + return cnp == 1; +} static inline bool supports_csv2p3(int scope) { diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c index 91e654e61f73..25bf46c7ce51 100644 --- a/arch/arm64/kernel/cpu_errata.c +++ b/arch/arm64/kernel/cpu_errata.c @@ -60,6 +60,15 @@ is_kryo_midr(const struct arm64_cpu_capabilities *entry, int scope) return model == entry->midr_range.model; } +#ifdef CONFIG_HISILICON_ERRATUM_162100125 +static bool +hisilicon_162100125_match(const struct arm64_cpu_capabilities *entry, + int scope) +{ + return is_affected_midr_range_list(entry, scope) && supports_cnp(scope); +} +#endif + #ifdef CONFIG_HISILICON_ERRATUM_1980005 static bool hisilicon_1980005_match(const struct arm64_cpu_capabilities *entry, @@ -661,7 +670,9 @@ const struct arm64_cpu_capabilities arm64_errata[] = { { .desc = "Hisilicon erratum 162100125", .capability = ARM64_WORKAROUND_HISILICON_ERRATUM_162100125, - ERRATA_MIDR_RANGE_LIST(hisilicon_erratum_162100125_cpus), + .matches = hisilicon_162100125_match, + .type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM, + .midr_range_list = hisilicon_erratum_162100125_cpus, }, #endif #ifdef CONFIG_HISILICON_ERRATUM_1980005 -- 2.33.0

2 1

[PATCH OLK-6.6] arm64: Add support for HIP09 Spectre-BHB mitigation
by Jinqian Yang 20 Oct '25

20 Oct '25

From: yangjinqian <yangjinqian1(a)huawei.com> virt inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IBN3WI ------------------------------------------------------------------------ The HIP09 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of HIP09 to the list for software mitigation. Signed-off-by: Jinqian Yang <yangjinqian1(a)huawei.com> Signed-off-by: Zhou Wang <wangzhou1(a)hisilicon.com> --- arch/arm64/kernel/proton-pack.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c index ff7ba4f013c5..fc014ccf9034 100644 --- a/arch/arm64/kernel/proton-pack.c +++ b/arch/arm64/kernel/proton-pack.c @@ -904,6 +904,7 @@ static u8 spectre_bhb_loop_affected(void) MIDR_ALL_VERSIONS(MIDR_CORTEX_A77), MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1), MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_GOLD), + MIDR_ALL_VERSIONS(MIDR_HISI_LINXICORE9100) {}, }; static const struct midr_range spectre_bhb_k11_list[] = { -- 2.33.0

2 1

[PATCH OLK-6.6] KVM: arm64: vgic-v4: Restore pending state on host userspace write
by Jinqian Yang 20 Oct '25

20 Oct '25

From: Marc Zyngier <maz(a)kernel.org> mainline inclusion from mainline-v6.8-rc1 commit 7b95382f965133ef61ce44aaabc518c16eb46909 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ID2P1J CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When the VMM writes to ISPENDR0 to set the state pending state of an SGI, we fail to convey this to the HW if this SGI is already backed by a GICv4.1 vSGI. This is a bit of a corner case, as this would only occur if the vgic state is changed on an already running VM, but this can apparently happen across a guest reset driven by the VMM. Fix this by always writing out the pending_latch value to the HW, and reseting it to false. Reported-by: Kunkun Jiang <jiangkunkun(a)huawei.com> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Reviewed-by: Zenghui Yu <yuzenghui(a)huawei.com> Cc: stable(a)vger.kernel.org # 5.10+ Link: https://lore.kernel.org/r/7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com Signed-off-by: Jinqian Yang <yangjinqian1(a)huawei.com> --- arch/arm64/kvm/vgic/vgic-mmio-v3.c | 58 +++++++++++++++++------------- 1 file changed, 34 insertions(+), 24 deletions(-) diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c index f9f47c91ee03..623160d51e54 100644 --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c @@ -384,33 +384,43 @@ static int vgic_v3_uaccess_write_pending(struct kvm_vcpu *vcpu, struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i); raw_spin_lock_irqsave(&irq->irq_lock, flags); - if (test_bit(i, &val)) { - /* - * pending_latch is set irrespective of irq type - * (level or edge) to avoid dependency that VM should - * restore irq config before pending info. - */ - irq->pending_latch = true; - vgic_queue_irq_unlock(vcpu->kvm, irq, flags); - } else { + + /* + * pending_latch is set irrespective of irq type + * (level or edge) to avoid dependency that VM should + * restore irq config before pending info. + */ + irq->pending_latch = test_bit(i, &val); + + if (irq->hw && vgic_irq_is_sgi(irq->intid)) { + irq_set_irqchip_state(irq->host_irq, + IRQCHIP_STATE_PENDING, + irq->pending_latch); + irq->pending_latch = false; + } + #ifdef CONFIG_VIRT_VTIMER_IRQ_BYPASS - /** - * workaround: On reset, userspace clears pending status - * for all PPIs and SGIs by writing all 0's to - * GICR_ISPENDR0. The pending state of vtimer interrupt - * is somehow staying in redistributor and we have to - * explicitly clear it... - * - * P.S., irq->vtimer_info is NULL on restore. - */ - if (irq->vtimer_info) - WARN_ON_ONCE(irq_set_irqchip_state(irq->host_irq, - IRQCHIP_STATE_PENDING, - false)); -#endif + /* + * workaround: On reset, userspace clears pending status + * for all PPIs and SGIs by writing all 0's to + * GICR_ISPENDR0. The pending state of vtimer interrupt + * is somehow staying in redistributor and we have to + * explicitly clear it... + * + * P.S., irq->vtimer_info is NULL on restore. + */ + if (irq->vtimer_info) { + WARN_ON_ONCE(irq_set_irqchip_state(irq->host_irq, + IRQCHIP_STATE_PENDING, + irq->pending_latch)); irq->pending_latch = false; - raw_spin_unlock_irqrestore(&irq->irq_lock, flags); } +#endif + + if (irq->pending_latch) + vgic_queue_irq_unlock(vcpu->kvm, irq, flags); + else + raw_spin_unlock_irqrestore(&irq->irq_lock, flags); vgic_put_irq(vcpu->kvm, irq); } -- 2.33.0

2 1

[PATCH openEuler-1.0-LTS] usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()
by Xia Fukun 20 Oct '25

20 Oct '25

From: Jianglei Nie <niejianglei2021(a)163.com> stable inclusion from stable-v4.19.262 commit ddab9fe76296840aad686c66888a9c1dfdbff5ff category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID0VIV CVE: CVE-2022-50544 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7e271f42a5cc3768cd2622b929ba66859ae21f97 ] xhci_alloc_stream_info() allocates stream context array for stream_info ->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs, stream_info->stream_ctx_array is not released, which will lead to a memory leak. We can fix it by releasing the stream_info->stream_ctx_array with xhci_free_stream_ctx() on the error path to avoid the potential memory leak. Signed-off-by: Jianglei Nie <niejianglei2021(a)163.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Link: https://lore.kernel.org/r/20220921123450.671459-2-mathias.nyman@linux.intel… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/usb/host/xhci-mem.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index b7ed214b757c..76d13bed7c15 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -650,7 +650,7 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct xhci_hcd *xhci, num_stream_ctxs, &stream_info->ctx_array_dma, mem_flags); if (!stream_info->stream_ctx_array) - goto cleanup_ctx; + goto cleanup_ring_array; memset(stream_info->stream_ctx_array, 0, sizeof(struct xhci_stream_ctx)*num_stream_ctxs); @@ -711,6 +711,11 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct xhci_hcd *xhci, } xhci_free_command(xhci, stream_info->free_streams_command); cleanup_ctx: + xhci_free_stream_ctx(xhci, + stream_info->num_stream_ctxs, + stream_info->stream_ctx_array, + stream_info->ctx_array_dma); +cleanup_ring_array: kfree(stream_info->stream_rings); cleanup_info: kfree(stream_info); -- 2.34.1

2 1

[PATCH OLK-6.6 v2] kvm: hisi_virt: tlbi: Fix wrong CPU aff3 convertion between MPIDR and SYS_LSUDVMBM_EL2
by Jinqian Yang 20 Oct '25

20 Oct '25

From: Zhou Wang <wangzhou1(a)hisilicon.com> driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICURZK --------------------------------------------------------------------- TLBI broadcast CPU bitmap should be set in SYS_LSUDVMBM_EL2. Now we make a mistake when doing the convertion between MPIDR and SYS_LSUDVMBM_EL2. Fields of vDie ID and Socket ID in Aff3 are different between MPIDR and SYS_LSUDVMBM_EL2p in HIP12, however, they are same in current wrong logic. This patch fixes this problem. Fixes: 2671ba221968 ("kvm: hisi_virt: Update TLBI broadcast feature for hip12") Signed-off-by: Zhou Wang <wangzhou1(a)hisilicon.com> --- arch/arm64/kvm/hisilicon/hisi_virt.c | 23 ++++++++++++++++++++--- arch/arm64/kvm/hisilicon/hisi_virt.h | 15 +++++++++++++-- 2 files changed, 33 insertions(+), 5 deletions(-) diff --git a/arch/arm64/kvm/hisilicon/hisi_virt.c b/arch/arm64/kvm/hisilicon/hisi_virt.c index 48b644e4b3f3..d1ff8e158665 100644 --- a/arch/arm64/kvm/hisilicon/hisi_virt.c +++ b/arch/arm64/kvm/hisilicon/hisi_virt.c @@ -8,6 +8,7 @@ #include <linux/init.h> #include <linux/kvm_host.h> #include "hisi_virt.h" +#include <linux/bitfield.h> static enum hisi_cpu_type cpu_type = UNKNOWN_HI_TYPE; @@ -475,12 +476,25 @@ static void kvm_update_vm_lsudvmbm(struct kvm *kvm) kvm->arch.tlbi_dvmbm = val; } +static u8 convert_aff3_to_vdie_hip12(u64 aff3) +{ + /* + * The fields of vdie id and socket id in MPIDR are aff3[2:0] and + * aff3[4:3], however, the fields of vdie id and socket id in + * SYS_LSUDVMBM_EL2 are bit[58:57] and bit[60:59] for first vdie, + * bit[54:53] and bit[56:55] for second vdie. + */ + return FIELD_GET(MPIDR_AFF3_SOCKET_ID_MASK, aff3) << 2 | + FIELD_GET(MPIDR_AFF3_VDIE_ID_MASK, aff3); +} + static void kvm_update_vm_lsudvmbm_hip12(struct kvm *kvm) { u64 mpidr, aff3, aff2; u64 vm_aff3s[DVMBM_MAX_DIES_HIP12]; u64 val; int cpu, nr_dies; + u8 vdie1, vdie2; nr_dies = kvm_dvmbm_get_dies_info(kvm, vm_aff3s, DVMBM_MAX_DIES_HIP12); if (nr_dies > 2) { @@ -489,8 +503,9 @@ static void kvm_update_vm_lsudvmbm_hip12(struct kvm *kvm) } if (nr_dies == 1) { + vdie1 = convert_aff3_to_vdie_hip12(vm_aff3s[0]); val = DVMBM_RANGE_ONE_DIE << DVMBM_RANGE_SHIFT | - vm_aff3s[0] << DVMBM_DIE1_VDIE_SHIFT_HIP12; + vdie1 << DVMBM_DIE1_VDIE_SHIFT_HIP12; /* fulfill bits [11:6] */ for_each_cpu(cpu, kvm->arch.sched_cpus) { @@ -504,10 +519,12 @@ static void kvm_update_vm_lsudvmbm_hip12(struct kvm *kvm) } /* nr_dies == 2 */ + vdie1 = convert_aff3_to_vdie_hip12(vm_aff3s[0]); + vdie2 = convert_aff3_to_vdie_hip12(vm_aff3s[1]); val = DVMBM_RANGE_TWO_DIES << DVMBM_RANGE_SHIFT | DVMBM_GRAN_CLUSTER << DVMBM_GRAN_SHIFT | - vm_aff3s[0] << DVMBM_DIE1_VDIE_SHIFT_HIP12 | - vm_aff3s[1] << DVMBM_DIE2_VDIE_SHIFT_HIP12; + vdie1 << DVMBM_DIE1_VDIE_SHIFT_HIP12 | + vdie2 << DVMBM_DIE2_VDIE_SHIFT_HIP12; /* and fulfill bits [11:0] */ for_each_cpu(cpu, kvm->arch.sched_cpus) { diff --git a/arch/arm64/kvm/hisilicon/hisi_virt.h b/arch/arm64/kvm/hisilicon/hisi_virt.h index 85dccafde8a6..395500bcf546 100644 --- a/arch/arm64/kvm/hisilicon/hisi_virt.h +++ b/arch/arm64/kvm/hisilicon/hisi_virt.h @@ -69,12 +69,23 @@ enum hisi_cpu_type { #define DVMBM_MAX_DIES 32 -/* HIP12 */ +/* + * MPIDR_EL1 layout on HIP12 + * + * Aff3[4:3] - socket ID [0-3] + * Aff3[2:0] - vdie ID [0,1] + * Aff2[2:0] - cluster ID [0-5] + * Aff1[3:0] - core ID [0-15] + * Aff0[0] - thread ID [0,1] + */ + #define DVMBM_DIE1_VDIE_SHIFT_HIP12 57 #define DVMBM_DIE2_VDIE_SHIFT_HIP12 53 #define DVMBM_DIE1_CLUSTER_SHIFT_HIP12 6 #define DVMBM_DIE2_CLUSTER_SHIFT_HIP12 0 -#define DVMBM_MAX_DIES_HIP12 8 +#define DVMBM_MAX_DIES_HIP12 8 +#define MPIDR_AFF3_VDIE_ID_MASK GENMASK(2, 0) +#define MPIDR_AFF3_SOCKET_ID_MASK GENMASK(4, 3) void probe_hisi_cpu_type(void); bool hisi_ncsnp_supported(void); -- 2.33.0

2 1

[PATCH OLK-5.10] KVM: arm64: vgic-v4: Restore pending state on host userspace write
by Jinqian Yang 20 Oct '25

20 Oct '25

From: Marc Zyngier <maz(a)kernel.org> mainline inclusion from mainline-v6.8-rc1 commit 7b95382f965133ef61ce44aaabc518c16eb46909 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ID2P1J CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When the VMM writes to ISPENDR0 to set the state pending state of an SGI, we fail to convey this to the HW if this SGI is already backed by a GICv4.1 vSGI. This is a bit of a corner case, as this would only occur if the vgic state is changed on an already running VM, but this can apparently happen across a guest reset driven by the VMM. Fix this by always writing out the pending_latch value to the HW, and reseting it to false. Reported-by: Kunkun Jiang <jiangkunkun(a)huawei.com> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Reviewed-by: Zenghui Yu <yuzenghui(a)huawei.com> Cc: stable(a)vger.kernel.org # 5.10+ Link: https://lore.kernel.org/r/7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com Signed-off-by: Jinqian Yang <yangjinqian1(a)huawei.com> --- arch/arm64/kvm/vgic/vgic-mmio-v3.c | 49 ++++++++++++++++-------------- 1 file changed, 26 insertions(+), 23 deletions(-) diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c index b6bdf22abab1..5d4282d4829d 100644 --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c @@ -377,32 +377,35 @@ static int vgic_v3_uaccess_write_pending(struct kvm_vcpu *vcpu, struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i); raw_spin_lock_irqsave(&irq->irq_lock, flags); - if (test_bit(i, &val)) { - /* - * pending_latch is set irrespective of irq type - * (level or edge) to avoid dependency that VM should - * restore irq config before pending info. - */ - irq->pending_latch = true; - vgic_queue_irq_unlock(vcpu->kvm, irq, flags); - } else { - /** - * workaround: On reset, userspace clears pending status - * for all PPIs and SGIs by writing all 0's to - * GICR_ISPENDR0. The pending state of vtimer interrupt - * is somehow staying in redistributor and we have to - * explicitly clear it... - * - * P.S., irq->vtimer_info is NULL on restore. - */ - if (irq->vtimer_info) - WARN_ON_ONCE(irq_set_irqchip_state(irq->host_irq, - IRQCHIP_STATE_PENDING, - false)); + + /* + * pending_latch is set irrespective of irq type + * (level or edge) to avoid dependency that VM should + * restore irq config before pending info. + */ + irq->pending_latch = test_bit(i, &val); + + /* + * workaround: On reset, userspace clears pending status + * for all PPIs and SGIs by writing all 0's to + * GICR_ISPENDR0. The pending state of vtimer interrupt + * is somehow staying in redistributor and we have to + * explicitly clear it... + * + * P.S., irq->vtimer_info is NULL on restore. + */ + if ((irq->hw && vgic_irq_is_sgi(irq->intid)) || irq->vtimer_info) { + irq_set_irqchip_state(irq->host_irq, + IRQCHIP_STATE_PENDING, + irq->pending_latch); irq->pending_latch = false; - raw_spin_unlock_irqrestore(&irq->irq_lock, flags); } + if (test_bit(i, &val)) + vgic_queue_irq_unlock(vcpu->kvm, irq, flags); + else + raw_spin_unlock_irqrestore(&irq->irq_lock, flags); + vgic_put_irq(vcpu->kvm, irq); } -- 2.33.0

2 1

[PATCH] [PATCH OLK-5.10] KVM: arm64: vgic-v4: Restore pending state on host userspace write
by Jinqian Yang 20 Oct '25

20 Oct '25

From: Marc Zyngier <maz(a)kernel.org> mainline inclusion from mainline-v6.8-rc1 commit 7b95382f965133ef61ce44aaabc518c16eb46909 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ID2P1J CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When the VMM writes to ISPENDR0 to set the state pending state of an SGI, we fail to convey this to the HW if this SGI is already backed by a GICv4.1 vSGI. This is a bit of a corner case, as this would only occur if the vgic state is changed on an already running VM, but this can apparently happen across a guest reset driven by the VMM. Fix this by always writing out the pending_latch value to the HW, and reseting it to false. Reported-by: Kunkun Jiang <jiangkunkun(a)huawei.com> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Reviewed-by: Zenghui Yu <yuzenghui(a)huawei.com> Cc: stable(a)vger.kernel.org # 5.10+ Link: https://lore.kernel.org/r/7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com Signed-off-by: Jinqian Yang <yangjinqian1(a)huawei.com> --- arch/arm64/kvm/vgic/vgic-mmio-v3.c | 49 ++++++++++++++++-------------- 1 file changed, 26 insertions(+), 23 deletions(-) diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c index b6bdf22abab1..5d4282d4829d 100644 --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c @@ -377,32 +377,35 @@ static int vgic_v3_uaccess_write_pending(struct kvm_vcpu *vcpu, struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i); raw_spin_lock_irqsave(&irq->irq_lock, flags); - if (test_bit(i, &val)) { - /* - * pending_latch is set irrespective of irq type - * (level or edge) to avoid dependency that VM should - * restore irq config before pending info. - */ - irq->pending_latch = true; - vgic_queue_irq_unlock(vcpu->kvm, irq, flags); - } else { - /** - * workaround: On reset, userspace clears pending status - * for all PPIs and SGIs by writing all 0's to - * GICR_ISPENDR0. The pending state of vtimer interrupt - * is somehow staying in redistributor and we have to - * explicitly clear it... - * - * P.S., irq->vtimer_info is NULL on restore. - */ - if (irq->vtimer_info) - WARN_ON_ONCE(irq_set_irqchip_state(irq->host_irq, - IRQCHIP_STATE_PENDING, - false)); + + /* + * pending_latch is set irrespective of irq type + * (level or edge) to avoid dependency that VM should + * restore irq config before pending info. + */ + irq->pending_latch = test_bit(i, &val); + + /* + * workaround: On reset, userspace clears pending status + * for all PPIs and SGIs by writing all 0's to + * GICR_ISPENDR0. The pending state of vtimer interrupt + * is somehow staying in redistributor and we have to + * explicitly clear it... + * + * P.S., irq->vtimer_info is NULL on restore. + */ + if ((irq->hw && vgic_irq_is_sgi(irq->intid)) || irq->vtimer_info) { + irq_set_irqchip_state(irq->host_irq, + IRQCHIP_STATE_PENDING, + irq->pending_latch); irq->pending_latch = false; - raw_spin_unlock_irqrestore(&irq->irq_lock, flags); } + if (test_bit(i, &val)) + vgic_queue_irq_unlock(vcpu->kvm, irq, flags); + else + raw_spin_unlock_irqrestore(&irq->irq_lock, flags); + vgic_put_irq(vcpu->kvm, irq); } -- 2.33.0

1 0