- Kernel - mailweb.openeuler.org

[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

[PATCH] [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

1 0

[PATCH OLK-6.6] 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 Die 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..a92ef8d775f0 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[0-2] and + * aff3[3,4], however, the fields of vdie id and socket id in + * SYS_LSUDVMBM_EL2 are bit[57,58] and bit[59,60] for first vdie, + * bit[53,54] and bit[55,56] 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) { + vide1 = convert_aff3_to_vdie_hip12(vm_aff3s[0]); val = DVMBM_RANGE_ONE_DIE << DVMBM_RANGE_SHIFT | - vm_aff3s[0] << DVMBM_DIE1_VDIE_SHIFT_HIP12; + vide1 << 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 */ + vide1 = convert_aff3_to_vdie_hip12(vm_aff3s[0]); + vide2 = 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

3 2

[PATCH qemu-8.2.0 0/2] Add ipiv=on/off option
by Jinqian Yang 20 Oct '25

20 Oct '25

Add `-accel kvm,ipiv=on` to enable ipiv on the virtual machine. Jinqian Yang (2): Revert "hw/arm/virt: Introduce a IPIV machine option" target/arm: add ipiv=on/off option hw/arm/virt.c | 19 ------------------- include/hw/arm/virt.h | 1 - include/sysemu/kvm_int.h | 1 + target/arm/kvm.c | 28 +++++++++++++++++++++++----- 4 files changed, 24 insertions(+), 25 deletions(-) -- 2.33.0

1 2

[PATCH OLK-6.6] dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees
by Chen Jinghuang 20 Oct '25

20 Oct '25

From: Stephan Gerhold <stephan.gerhold(a)linaro.org> stable inclusion from stable-v6.6.107 commit ebf6c7c908e5999531c3517289598f187776124f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID0R5A CVE: CVE-2025-39923 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 5068b5254812433e841a40886e695633148d362d upstream. When we don't have a clock specified in the device tree, we have no way to ensure the BAM is on. This is often the case for remotely-controlled or remotely-powered BAM instances. In this case, we need to read num-channels from the DT to have all the necessary information to complete probing. However, at the moment invalid device trees without clock and without num-channels still continue probing, because the error handling is missing return statements. The driver will then later try to read the number of channels from the registers. This is unsafe, because it relies on boot firmware and lucky timing to succeed. Unfortunately, the lack of proper error handling here has been abused for several Qualcomm SoCs upstream, causing early boot crashes in several situations [1, 2]. Avoid these early crashes by erroring out when any of the required DT properties are missing. Note that this will break some of the existing DTs upstream (mainly BAM instances related to the crypto engine). However, clearly these DTs have never been tested properly, since the error in the kernel log was just ignored. It's safer to disable the crypto engine for these broken DTBs. [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/ [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linar… Cc: stable(a)vger.kernel.org Fixes: 48d163b1aa6e ("dmaengine: qcom: bam_dma: get num-channels and num-ees from dt") Signed-off-by: Stephan Gerhold <stephan.gerhold(a)linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250212-bam-dma-fixes-v1-8-f560889e65d8@linaro.o… Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- drivers/dma/qcom/bam_dma.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c index 4c3eb972039d..d5882c8537e5 100644 --- a/drivers/dma/qcom/bam_dma.c +++ b/drivers/dma/qcom/bam_dma.c @@ -1283,13 +1283,17 @@ static int bam_dma_probe(struct platform_device *pdev) if (!bdev->bamclk) { ret = of_property_read_u32(pdev->dev.of_node, "num-channels", &bdev->num_channels); - if (ret) + if (ret) { dev_err(bdev->dev, "num-channels unspecified in dt\n"); + return ret; + } ret = of_property_read_u32(pdev->dev.of_node, "qcom,num-ees", &bdev->num_ees); - if (ret) + if (ret) { dev_err(bdev->dev, "num-ees unspecified in dt\n"); + return ret; + } } ret = clk_prepare_enable(bdev->bamclk); -- 2.34.1

2 1