Conversation
kvm_restore_timer() rebuilds the remaining timer countdown value from vcpu->arch.expire, which is host-internal and is not part of the migrated vCPU state. On the migration destination it is still 0, so for a one-shot timer that has not expired yet the computed delta is 0 and write_gcsr_timertick(0) injects the timer interrupt immediately instead of after the remaining time. The expired one-shot case (TVAL = -1) is already handled earlier. When expire has not been set (i.e. on the migration destination), reload the remaining countdown value from the migrated TVAL. This covers both one- shot and periodic timers. The regular preempt/resume path on the source, where expire is valid, is unchanged. Fixes: a5857b9 ("LoongArch: KVM: Implement vcpu timer operations") Suggested-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Tao Cui <cuitao@kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> (cherry picked from commit fe41c0759b11b982f945633b7abb4b49dfaf8ce4) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
A guest can write CSR.TCFG with the periodic bit set but a period value of zero. When kvm_restore_timer() later enters the periodic branch, period = cfg & CSR_TCFG_VAL evaluates to 0, causing (delta % period) to trigger a division by zero and crash the host kernel. Clamp the period to 1 to avoid the panic. Fixes: a5857b9 ("LoongArch: KVM: Implement vcpu timer operations") Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Tao Cui <cuitao@kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> (cherry picked from commit 01c823f14ed4caac4bf1ceb90926f26d67d753ec) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Variable vector[] is declared on stack in function dmsintc_inject_irq() and sometimes it is used without initialized. Here fix this issue. Cc: stable@vger.kernel.org Fixes: 03de5ee ("LoongArch: KVM: Add DMSINTC inject msi to vCPU") Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> (cherry picked from commit 81aa3a58b542ed88819115c80a17acd86eacb89d) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
kvm_loongarch_init() calls kvm_loongarch_env_init() to allocate the per-CPU kvm_context (vmcs) and kvm_loongarch_ops and to register the perf callbacks, and then calls kvm_init(). If kvm_init() fails its result is returned directly, but since module_init() does not run the module_exit() stuff on failure, so kvm_loongarch_env_exit() is never called and those resources are leaked. So call kvm_loongarch_env_exit() when kvm_init() fails, matching the teardown-on-failure pattern used by riscv_kvm_init(). Cc: stable@vger.kernel.org Fixes: 2bd6ac6 ("LoongArch: KVM: Implement kvm module related interface") Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Chaithanya Lagisetty <nagachaithanya9911@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> (cherry picked from commit f7a1064cce3b100b54780c68529176232d8eb01e) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
kvm_arch_prepare_memory_region() computes new->arch.flags, i.e. whether a memslot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE, only for KVM_MR_CREATE and KVM_MR_MOVE, and returns early for every other change. But the generic code allocates a zeroed memslot for every change and never copies old->arch, so after a KVM_MR_FLAGS_ONLY update, e.g. toggling KVM_MEM_LOG_DIRTY_PAGES for live migration, the active memslot has arch.flags == 0. With both flags clear, fault_supports_huge_mapping() falls through to the alignment check on the HVA range alone, which no longer verifies that the GPA and HVA have the same offset within a PMD. A memslot that was marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can then be mapped with PMD entries on read faults, and since kvm_map_page() aligns the gfn and the pfn independently, the guest ends up accessing the wrong host pages, exactly the "d -> f, e -> g" case described in the comment above the check. Carry the arch flags over from the old memslot for KVM_MR_FLAGS_ONLY, as the GPA, HVA and size are guaranteed to be unchanged for that case. Cc: stable@vger.kernel.org Fixes: 7ab6fb5 ("LoongArch: KVM: Optimization for memslot hugepage checking") Tested-by: Tao Cui <cuitao@kylinos.cn> Reviewed-by: Tao Cui <cuitao@kylinos.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Zeng Chi <zengchi@kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> (cherry picked from commit 27a9bfee3bbcb3cabb77797354f07e0e44e49831) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
pch_msi_set_irq() passes e->msi.data straight into eiointc_set_irq() as the irq number. The MSI data comes from userspace, that either via a KVM_IRQ_ROUTING_MSI entry set with KVM_SET_GSI_ROUTING (used by irqfd and KVM_IRQ_LINE) or directly via KVM_SIGNAL_MSI, and is never checked against EIOINTC_IRQS. eiointc_set_irq() uses the value with __set_bit()/__clear_bit() on the 256-bit isr bitmap, eiointc_update_irq() then indexes sw_coremap[] and the per-cpu coreisr/sw_coreisr bitmaps with it. Therefore a data value >= 256 reads and writes memory past the end of those arrays, i.e. any process holding a VM fd can corrupt kernel memory beyond the allocation of loongarch_eiointc. Reject MSI data that doesn't fit in the EIOINTC irq space. The DMSINTC path is unaffected as it decodes the vector from the address and masks it. Cc: stable@vger.kernel.org Fixes: 1928254 ("LoongArch: KVM: Add irqfd support") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260531140921.1B1181F00893@smtp.kernel.org/ Reviewed-by: Tao Cui <cuitao@kylinos.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Zeng Chi <zengchi@kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> (cherry picked from commit 501514d6ebd2111c353a1296f25dbe22fbd64657) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist many objtool warnings "sibling call from callable instruction with modified stack frame". For this special case, the related object file shows that there is no generated relocation section '.rela.discard.tablejump_annotate' for the table jump instruction jirl, thus objtool can not know that what is the actual destination address. It needs to do something on the LLVM side to make sure that there is the relocation section '.rela.discard.tablejump_annotate' if LTO is enabled, but in order to maintain compatibility for the current LLVM compiler, this can be done in the kernel Makefile for now. Ensure it is aware of linker with LTO, '--loongarch-annotate-tablejump' needs to be passed via '-mllvm' to ld.lld. Before doing the above changes, it should handle the special case of the relocation section '.rela.discard.tablejump_annotate' to get the correct table size first, otherwise there are many objtool warnings and errors if LTO is enabled. There are many different rodata for each function if LTO is enabled, it is necessary to enhance get_rodata_table_size_by_table_annotate(). Fixes: b95f852 ("objtool/LoongArch: Add support for switch table") Closes: https://lore.kernel.org/loongarch/20250731175655.GA1455142@ax162/ Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> (cherry picked from commit a47bc95) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist many objtool warnings "sibling call from callable instruction with modified stack frame". For this special case, the related object file shows that there is no generated relocation section '.rela.discard.tablejump_annotate' for the table jump instruction jirl, thus objtool can not know that what is the actual destination address. It needs to do something on the LLVM side to make sure that there is the relocation section '.rela.discard.tablejump_annotate' if LTO is enabled, but in order to maintain compatibility for the current LLVM compiler, this can be done in the kernel Makefile for now. Ensure it is aware of linker with LTO, '--loongarch-annotate-tablejump' needs to be passed via '-mllvm' to ld.lld. Note that it should also pass the compiler option -mannotate-tablejump rather than only pass '-mllvm --loongarch-annotate-tablejump' to ld.lld if LTO is enabled, otherwise there are no jump info for some table jump instructions. Fixes: e20ab7d ("LoongArch: Enable jump table for objtool") Closes: https://lore.kernel.org/loongarch/20250731175655.GA1455142@ax162/ Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Co-developed-by: WANG Rui <wangrui@loongson.cn> Signed-off-by: WANG Rui <wangrui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> (cherry picked from commit 5dfea66) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Sashiko reported that the irqchip index is not validated for LoongArch. Add validation and reject out-of-range irqchip indexes to avoid indexing past the routing table's chip array. Cc: stable@vger.kernel.org Fixes: 1928254 ("LoongArch: KVM: Add irqfd support") Closes: https://lore.kernel.org/kvm/20260525051714.485D51F000E9@smtp.kernel.org/ Reported-by: Sashiko <sashiko-bot@kernel.org> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Yanfei Xu <yanfei.xu@bytedance.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> (cherry picked from commit 3474037) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
In function kvm_make_vcpu_request(), it will send IPI to physical CPU when vCPU is in IN_GUEST_MODE mode. And physical CPU is set in function kvm_check_vpid(), thus it should be called before IN_GUEST_MODE is set. Otherwise IPI will send to wrong old physical CPU where vCPU is running. Cc: stable@vger.kernel.org Fixes: 2fc3bd8 ("LoongArch: KVM: Implement basic vcpu interfaces") Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> (cherry picked from commit 32d05564a6128d59ea876cf9078fe6866a809e14) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Reviewer's GuideSyncs upstream LoongArch fixes across the build and objtool pipeline plus KVM, adding LTO-aware jump-table annotations, stricter interrupt input validation, robust initialization rollback, correct memslot and migrated-timer state handling, and safer vCPU/objtool processing. Sequence diagram for KVM LoongArch initialization rollbacksequenceDiagram
participant Init as kvm_loongarch_init
participant Env as kvm_loongarch_env_init
participant IPI as IPI device
participant EIO as EIOINTC device
participant PCH as PCH PIC device
participant DMS as DMSINTC device
participant Cleanup as kvm_loongarch_env_exit
Init->>Env: kvm_loongarch_env_init()
Env->>IPI: kvm_loongarch_register_ipi_device()
Env->>EIO: kvm_loongarch_register_eiointc_device()
Env->>PCH: kvm_loongarch_register_pch_pic_device()
Env->>DMS: kvm_loongarch_register_dmsintc_device()
alt registration failure
Env->>PCH: kvm_loongarch_unregister_pch_pic_device()
Env->>EIO: kvm_loongarch_unregister_eiointc_device()
Env->>IPI: kvm_loongarch_unregister_ipi_device()
end
Init->>Init: kvm_init()
alt kvm_init failure
Init->>Cleanup: kvm_loongarch_env_exit()
Cleanup->>DMS: kvm_loongarch_unregister_dmsintc_device()
Cleanup->>PCH: kvm_loongarch_unregister_pch_pic_device()
Cleanup->>EIO: kvm_loongarch_unregister_eiointc_device()
Cleanup->>IPI: kvm_loongarch_unregister_ipi_device()
end
State diagram for migrated LoongArch KVM timer restorationstateDiagram-v2
[*] --> RestoreTimer
RestoreTimer --> ReloadTVAL: expire == 0
ReloadTVAL --> OneShot: ticks < cfg
ReloadTVAL --> PeriodicOrExpired: ticks >= cfg
RestoreTimer --> ExistingExpiry: expire != 0
OneShot --> RecalculateExpiry
PeriodicOrExpired --> RecalculateExpiry
ExistingExpiry --> RecalculateExpiry
RecalculateExpiry --> PeriodicCorrection: CSR_TCFG_PERIOD
RecalculateExpiry --> ArmTimer: one-shot
PeriodicCorrection --> ArmTimer
ArmTimer --> [*]
Flow diagram for LoongArch KVM interrupt validationflowchart TD
A["KVM routing entry"] --> B{"IRQ chip pin valid?"}
B -- No --> X["Reject entry"]
B -- Yes --> C{"IRQ chip index valid?"}
C -- No --> X
C -- Yes --> D{"MSI data below EIOINTC_IRQS?"}
D -- No --> X
D -- Yes --> E["eiointc_set_irq()"]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
opsiff
force-pushed
the
linux-6.6.y-2026-09-14-loongarch
branch
from
September 14, 2026 04:16
d58a03b to
87c3466
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by Sourcery
Sync upstream LoongArch fixes to improve kernel build handling and KVM correctness.
Bug Fixes:
Enhancements:
Build: