From: Bibo Mao <maobibo@loongson.cn>
To: Huacai Chen <chenhuacai@kernel.org>
Cc: Jinyang He <hejinyang@loongson.cn>,
lixianglai <lixianglai@loongson.cn>,
Tiezhu Yang <yangtiezhu@loongson.cn>,
loongarch@lists.linux.dev, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, stable@vger.kernel.org,
WANG Xuerui <kernel@xen0n.name>,
Tianrui Zhao <zhaotianrui@loongson.cn>,
Charlie Jenkins <charlie@rivosinc.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH V3 2/2] LoongArch: KVM: fix "unreliable stack" issue
Date: Mon, 13 Apr 2026 11:56:29 +0800 [thread overview]
Message-ID: <1c542bd9-1e76-fd30-8a26-ed3ab0d965c9@loongson.cn> (raw)
In-Reply-To: <CAAhV-H7D801S5SRvQzWYv0m3b-HYz-P_AfGwQdaXZvOfXVEhCA@mail.gmail.com>
On 2026/4/13 上午11:11, Huacai Chen wrote:
> On Mon, Apr 13, 2026 at 9:01 AM Bibo Mao <maobibo@loongson.cn> wrote:
>>
>>
>>
>> On 2026/4/11 下午10:24, Huacai Chen wrote:
>>> On Wed, Apr 8, 2026 at 9:26 AM Bibo Mao <maobibo@loongson.cn> wrote:
>>>>
>>>>
>>>>
>>>> On 2025/12/30 下午1:53, Jinyang He wrote:
>>>>> On 2025-12-30 12:03, Bibo Mao wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 2025/12/30 上午11:36, Jinyang He wrote:
>>>>>>> On 2025-12-30 10:24, Bibo Mao wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2025/12/29 下午6:41, Jinyang He wrote:
>>>>>>>>> On 2025-12-29 18:11, lixianglai wrote:
>>>>>>>>>
>>>>>>>>>> Hi Jinyang:
>>>>>>>>>>>
>>>>>>>>>>> On 2025-12-29 11:53, lixianglai wrote:
>>>>>>>>>>>> Hi Jinyang:
>>>>>>>>>>>>> On 2025-12-27 09:27, Xianglai Li wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Insert the appropriate UNWIND macro definition into the
>>>>>>>>>>>>>> kvm_exc_entry in
>>>>>>>>>>>>>> the assembly function to guide the generation of correct ORC
>>>>>>>>>>>>>> table entries,
>>>>>>>>>>>>>> thereby solving the timeout problem of loading the
>>>>>>>>>>>>>> livepatch-sample module
>>>>>>>>>>>>>> on a physical machine running multiple vcpus virtual machines.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> While solving the above problems, we have gained an additional
>>>>>>>>>>>>>> benefit,
>>>>>>>>>>>>>> that is, we can obtain more call stack information
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Stack information that can be obtained before the problem is
>>>>>>>>>>>>>> fixed:
>>>>>>>>>>>>>> [<0>] kvm_vcpu_block+0x88/0x120 [kvm]
>>>>>>>>>>>>>> [<0>] kvm_vcpu_halt+0x68/0x580 [kvm]
>>>>>>>>>>>>>> [<0>] kvm_emu_idle+0xd4/0xf0 [kvm]
>>>>>>>>>>>>>> [<0>] kvm_handle_gspr+0x7c/0x700 [kvm]
>>>>>>>>>>>>>> [<0>] kvm_handle_exit+0x160/0x270 [kvm]
>>>>>>>>>>>>>> [<0>] kvm_exc_entry+0x100/0x1e0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Stack information that can be obtained after the problem is
>>>>>>>>>>>>>> fixed:
>>>>>>>>>>>>>> [<0>] kvm_vcpu_block+0x88/0x120 [kvm]
>>>>>>>>>>>>>> [<0>] kvm_vcpu_halt+0x68/0x580 [kvm]
>>>>>>>>>>>>>> [<0>] kvm_emu_idle+0xd4/0xf0 [kvm]
>>>>>>>>>>>>>> [<0>] kvm_handle_gspr+0x7c/0x700 [kvm]
>>>>>>>>>>>>>> [<0>] kvm_handle_exit+0x160/0x270 [kvm]
>>>>>>>>>>>>>> [<0>] kvm_exc_entry+0x104/0x1e4
>>>>>>>>>>>>>> [<0>] kvm_enter_guest+0x38/0x11c
>>>>>>>>>>>>>> [<0>] kvm_arch_vcpu_ioctl_run+0x26c/0x498 [kvm]
>>>>>>>>>>>>>> [<0>] kvm_vcpu_ioctl+0x200/0xcf8 [kvm]
>>>>>>>>>>>>>> [<0>] sys_ioctl+0x498/0xf00
>>>>>>>>>>>>>> [<0>] do_syscall+0x98/0x1d0
>>>>>>>>>>>>>> [<0>] handle_syscall+0xb8/0x158
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cc: stable@vger.kernel.org
>>>>>>>>>>>>>> Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>> Cc: Huacai Chen <chenhuacai@kernel.org>
>>>>>>>>>>>>>> Cc: WANG Xuerui <kernel@xen0n.name>
>>>>>>>>>>>>>> Cc: Tianrui Zhao <zhaotianrui@loongson.cn>
>>>>>>>>>>>>>> Cc: Bibo Mao <maobibo@loongson.cn>
>>>>>>>>>>>>>> Cc: Charlie Jenkins <charlie@rivosinc.com>
>>>>>>>>>>>>>> Cc: Xianglai Li <lixianglai@loongson.cn>
>>>>>>>>>>>>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>>>>>>>>>>>>> Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> arch/loongarch/kvm/switch.S | 28 +++++++++++++++++++---------
>>>>>>>>>>>>>> 1 file changed, 19 insertions(+), 9 deletions(-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/arch/loongarch/kvm/switch.S
>>>>>>>>>>>>>> b/arch/loongarch/kvm/switch.S
>>>>>>>>>>>>>> index 93845ce53651..a3ea9567dbe5 100644
>>>>>>>>>>>>>> --- a/arch/loongarch/kvm/switch.S
>>>>>>>>>>>>>> +++ b/arch/loongarch/kvm/switch.S
>>>>>>>>>>>>>> @@ -10,6 +10,7 @@
>>>>>>>>>>>>>> #include <asm/loongarch.h>
>>>>>>>>>>>>>> #include <asm/regdef.h>
>>>>>>>>>>>>>> #include <asm/unwind_hints.h>
>>>>>>>>>>>>>> +#include <linux/kvm_types.h>
>>>>>>>>>>>>>> #define HGPR_OFFSET(x) (PT_R0 + 8*x)
>>>>>>>>>>>>>> #define GGPR_OFFSET(x) (KVM_ARCH_GGPR + 8*x)
>>>>>>>>>>>>>> @@ -110,9 +111,9 @@
>>>>>>>>>>>>>> * need to copy world switch code to DMW area.
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>> .text
>>>>>>>>>>>>>> + .p2align PAGE_SHIFT
>>>>>>>>>>>>>> .cfi_sections .debug_frame
>>>>>>>>>>>>>> SYM_CODE_START(kvm_exc_entry)
>>>>>>>>>>>>>> - .p2align PAGE_SHIFT
>>>>>>>>>>>>>> UNWIND_HINT_UNDEFINED
>>>>>>>>>>>>>> csrwr a2, KVM_TEMP_KS
>>>>>>>>>>>>>> csrrd a2, KVM_VCPU_KS
>>>>>>>>>>>>>> @@ -170,6 +171,7 @@ SYM_CODE_START(kvm_exc_entry)
>>>>>>>>>>>>>> /* restore per cpu register */
>>>>>>>>>>>>>> ld.d u0, a2, KVM_ARCH_HPERCPU
>>>>>>>>>>>>>> addi.d sp, sp, -PT_SIZE
>>>>>>>>>>>>>> + UNWIND_HINT_REGS
>>>>>>>>>>>>>> /* Prepare handle exception */
>>>>>>>>>>>>>> or a0, s0, zero
>>>>>>>>>>>>>> @@ -200,7 +202,7 @@ ret_to_host:
>>>>>>>>>>>>>> jr ra
>>>>>>>>>>>>>> SYM_CODE_END(kvm_exc_entry)
>>>>>>>>>>>>>> -EXPORT_SYMBOL(kvm_exc_entry)
>>>>>>>>>>>>>> +EXPORT_SYMBOL_FOR_KVM(kvm_exc_entry)
>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>> * int kvm_enter_guest(struct kvm_run *run, struct kvm_vcpu
>>>>>>>>>>>>>> *vcpu)
>>>>>>>>>>>>>> @@ -215,6 +217,14 @@ SYM_FUNC_START(kvm_enter_guest)
>>>>>>>>>>>>>> /* Save host GPRs */
>>>>>>>>>>>>>> kvm_save_host_gpr a2
>>>>>>>>>>>>>> + /*
>>>>>>>>>>>>>> + * The csr_era member variable of the pt_regs structure
>>>>>>>>>>>>>> is required
>>>>>>>>>>>>>> + * for unwinding orc to perform stack traceback, so we
>>>>>>>>>>>>>> need to put
>>>>>>>>>>>>>> + * pc into csr_era member variable here.
>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>> + pcaddi t0, 0
>>>>>>>>>>>>>> + st.d t0, a2, PT_ERA
>>>>>>>>>>>>> Hi, Xianglai,
>>>>>>>>>>>>>
>>>>>>>>>>>>> It should use `SYM_CODE_START` to mark the `kvm_enter_guest`
>>>>>>>>>>>>> rather than
>>>>>>>>>>>>> `SYM_FUNC_START`, since the `SYM_FUNC_START` is used to mark
>>>>>>>>>>>>> "C-likely"
>>>>>>>>>>>>> asm functionw.
>>>>>>>>>>>>
>>>>>>>>>>>> Ok, I will use SYM_CODE_START to mark kvm_enter_guest in the
>>>>>>>>>>>> next version.
>>>>>>>>>>>>
>>>>>>>>>>>>> I guess the kvm_enter_guest is something like exception
>>>>>>>>>>>>> handler becuase the last instruction is "ertn". So usually it
>>>>>>>>>>>>> should
>>>>>>>>>>>>> mark UNWIND_HINT_REGS where can find last frame info by "$sp".
>>>>>>>>>>>>> However, all info is store to "$a2", this mark should be
>>>>>>>>>>>>> `UNWIND_HINT sp_reg=ORC_REG_A2(???) type=UNWIND_HINT_TYPE_REGS`.
>>>>>>>>>>>>> I don't konw why save this function internal PC here by `pcaddi
>>>>>>>>>>>>> t0, 0`,
>>>>>>>>>>>>> and I think it is no meaning(, for exception handler, they save
>>>>>>>>>>>>> last PC
>>>>>>>>>>>>> by read CSR.ERA). The `kvm_enter_guest` saves registers by
>>>>>>>>>>>>> "$a2"("$sp" - PT_REGS) beyond stack ("$sp"), it is dangerous if IE
>>>>>>>>>>>>> is enable. So I wonder if there is really a stacktrace through
>>>>>>>>>>>>> this function?
>>>>>>>>>>>>>
>>>>>>>>>>>> The stack backtracking issue in switch.S is rather complex
>>>>>>>>>>>> because it involves the switching between cpu root-mode and
>>>>>>>>>>>> guest-mode:
>>>>>>>>>>>> Real stack backtracking should be divided into two parts:
>>>>>>>>>>>> part 1:
>>>>>>>>>>>> [<0>] kvm_enter_guest+0x38/0x11c
>>>>>>>>>>>> [<0>] kvm_arch_vcpu_ioctl_run+0x26c/0x498 [kvm]
>>>>>>>>>>>> [<0>] kvm_vcpu_ioctl+0x200/0xcf8 [kvm]
>>>>>>>>>>>> [<0>] sys_ioctl+0x498/0xf00
>>>>>>>>>>>> [<0>] do_syscall+0x98/0x1d0
>>>>>>>>>>>> [<0>] handle_syscall+0xb8/0x158
>>>>>>>>>>>>
>>>>>>>>>>>> part 2:
>>>>>>>>>>>> [<0>] kvm_vcpu_block+0x88/0x120 [kvm]
>>>>>>>>>>>> [<0>] kvm_vcpu_halt+0x68/0x580 [kvm]
>>>>>>>>>>>> [<0>] kvm_emu_idle+0xd4/0xf0 [kvm]
>>>>>>>>>>>> [<0>] kvm_handle_gspr+0x7c/0x700 [kvm]
>>>>>>>>>>>> [<0>] kvm_handle_exit+0x160/0x270 [kvm]
>>>>>>>>>>>> [<0>] kvm_exc_entry+0x104/0x1e4
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> In "part 1", after executing kvm_enter_guest, the cpu switches
>>>>>>>>>>>> from root-mode to guest-mode.
>>>>>>>>>>>> In this case, stack backtracking is indeed very rare.
>>>>>>>>>>>>
>>>>>>>>>>>> In "part 2", the cpu switches from the guest-mode to the root-mode,
>>>>>>>>>>>> and most of the stack backtracking occurs during this phase.
>>>>>>>>>>>>
>>>>>>>>>>>> To obtain the longest call chain, we save pc in kvm_enter_guest
>>>>>>>>>>>> to pt_regs.csr_era,
>>>>>>>>>>>> and after restoring the sp of the root-mode cpu in kvm_exc_entry,
>>>>>>>>>>>> The ORC entry was re-established using "UNWIND_HINT_REGS",
>>>>>>>>>>>> and then we obtained the following stack backtrace as we wanted:
>>>>>>>>>>>>
>>>>>>>>>>>> [<0>] kvm_vcpu_block+0x88/0x120 [kvm]
>>>>>>>>>>>> [<0>] kvm_vcpu_halt+0x68/0x580 [kvm]
>>>>>>>>>>>> [<0>] kvm_emu_idle+0xd4/0xf0 [kvm]
>>>>>>>>>>>> [<0>] kvm_handle_gspr+0x7c/0x700 [kvm]
>>>>>>>>>>>> [<0>] kvm_handle_exit+0x160/0x270 [kvm]
>>>>>>>>>>>> [<0>] kvm_exc_entry+0x104/0x1e4
>>>>>>>>>>> I found this might be a coincidence—correct behavior due to the
>>>>>>>>>>> incorrect
>>>>>>>>>>> UNWIND_HINT_REGS mark and unusual stack adjustment.
>>>>>>>>>>>
>>>>>>>>>>> First, the kvm_enter_guest contains only a single branch
>>>>>>>>>>> instruction, ertn.
>>>>>>>>>>> It hardware-jump to the CSR.ERA address directly, jump into
>>>>>>>>>>> kvm_exc_entry.
>>>>>>>>>>>
>>>>>>>>>>> At this point, the stack layout looks like this:
>>>>>>>>>>> -------------------------------
>>>>>>>>>>> frame from call to `kvm_enter_guest`
>>>>>>>>>>> ------------------------------- <- $sp
>>>>>>>>>>> PT_REGS
>>>>>>>>>>> ------------------------------- <- $a2
>>>>>>>>>>>
>>>>>>>>>>> Then kvm_exc_entry adjust stack without save any register (e.g.
>>>>>>>>>>> $ra, $sp)
>>>>>>>>>>> but still marked UNWIND_HINT_REGS.
>>>>>>>>>>> After the adjustment:
>>>>>>>>>>> -------------------------------
>>>>>>>>>>> frame from call to `kvm_enter_guest`
>>>>>>>>>>> -------------------------------
>>>>>>>>>>> PT_REGS
>>>>>>>>>>> ------------------------------- <- $a2, new $sp
>>>>>>>>>>>
>>>>>>>>>>> During unwinding, when the unwinder reaches kvm_exc_entry,
>>>>>>>>>>> it meets the mark of PT_REGS and correctly recovers
>>>>>>>>>>> pc = regs.csr_era, sp = regs.sp, ra = regs.ra
>>>>>>>>>>>
>>>>>>>>>> Yes, here unwinder does work as you say.
>>>>>>>>>>
>>>>>>>>>>> a) Can we avoid "ertn" rather than `jr reg (or jirl ra, reg, 0)`
>>>>>>>>>>> instead, like call?
>>>>>>>>>> No, we need to rely on the 'ertn instruction return PIE to CRMD IE,
>>>>>>>>>> at the same time to ensure that its atomic,
>>>>>>>>>> there should be no other instruction than' ertn 'more appropriate
>>>>>>>>>> here.
>>>>>>>>> You are right! I got it.
>>>>>>>>>>
>>>>>>>>>>> The kvm_exc_entry cannot back to kvm_enter_guest
>>>>>>>>>>> if we use "ertn", so should the kvm_enter_guest appear on the
>>>>>>>>>>> stacktrace?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It is flexible. As I mentioned above, the cpu completes the switch
>>>>>>>>>> from host-mode to guest mode through kvm_enter_guest,
>>>>>>>>>> and then the switch from guest mode to host-mode through
>>>>>>>>>> kvm_exc_entry. When we ignore the details of the host-mode
>>>>>>>>>> and guest-mode switching in the middle, we can understand that the
>>>>>>>>>> host cpu has completed kvm_enter_guest->kvm_exc_entry.
>>>>>>>>>> From this perspective, I think it can exist in the call stack, and
>>>>>>>>>> at the same time, we have obtained the maximum call stack
>>>>>>>>>> information.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> b) Can we adjust $sp before entering kvm_exc_entry? Then we can mark
>>>>>>>>>>> UNWIND_HINT_REGS at the beginning of kvm_exc_entry, which something
>>>>>>>>>>> like ret_from_kernel_thread_asm.
>>>>>>>>>>>
>>>>>>>>>> The following command can be used to dump the orc entries of the
>>>>>>>>>> kernel:
>>>>>>>>>> ./tools/objtool/objtool --dump vmlinux
>>>>>>>>>>
>>>>>>>>>> You can observe that not all orc entries are generated at the
>>>>>>>>>> beginning of the function.
>>>>>>>>>> For example:
>>>>>>>>>> handle_tlb_protect
>>>>>>>>>> ftrace_stub
>>>>>>>>>> handle_reserved
>>>>>>>>>>
>>>>>>>>>> So, is it unnecessary for us to modify UNWIND_HINT_REGS in order
>>>>>>>>>> to place it at the beginning of the function.
>>>>>>>>>>
>>>>>>>>>> If you have a better solution, could you provide an example of the
>>>>>>>>>> modification?
>>>>>>>>>> I can test the feasibility of the solution.
>>>>>>>>>>
>>>>>>>>> The expression at the beginning of the function is incorrect
>>>>>>>>> (feeling sorry).
>>>>>>>>> It should be marked where have all stacktrace info.
>>>>>>>>> Thanks for all the explaining, since I'm unfamiliar with kvm, I
>>>>>>>>> need these to help my understanding.
>>>>>>>>>
>>>>>>>>> Can you try with follows, with save regs by $sp, set more precise
>>>>>>>>> era to pt_regs, and more unwind hint.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> diff --git a/arch/loongarch/kvm/switch.S b/arch/loongarch/kvm/switch.S
>>>>>>>>> index f1768b7a6194..8ed1d7b72c54 100644
>>>>>>>>> --- a/arch/loongarch/kvm/switch.S
>>>>>>>>> +++ b/arch/loongarch/kvm/switch.S
>>>>>>>>> @@ -14,13 +14,13 @@
>>>>>>>>> #define GGPR_OFFSET(x) (KVM_ARCH_GGPR + 8*x)
>>>>>>>>>
>>>>>>>>> .macro kvm_save_host_gpr base
>>>>>>>>> - .irp n,1,2,3,22,23,24,25,26,27,28,29,30,31
>>>>>>>>> + .irp n,1,2,22,23,24,25,26,27,28,29,30,31
>>>>>>>>> st.d $r\n, \base, HGPR_OFFSET(\n)
>>>>>>>>> .endr
>>>>>>>>> .endm
>>>>>>>>>
>>>>>>>>> .macro kvm_restore_host_gpr base
>>>>>>>>> - .irp n,1,2,3,22,23,24,25,26,27,28,29,30,31
>>>>>>>>> + .irp n,1,2,22,23,24,25,26,27,28,29,30,31
>>>>>>>>> ld.d $r\n, \base, HGPR_OFFSET(\n)
>>>>>>>>> .endr
>>>>>>>>> .endm
>>>>>>>>> @@ -88,6 +88,7 @@
>>>>>>>>> /* Load KVM_ARCH register */
>>>>>>>>> ld.d a2, a2, (KVM_ARCH_GGPR + 8 * REG_A2)
>>>>>>>>>
>>>>>>>>> +111:
>>>>>>>>> ertn /* Switch to guest: GSTAT.PGM = 1, ERRCTL.ISERR = 0,
>>>>>>>>> TLBRPRMD.ISTLBR = 0 */
>>>>>>>>> .endm
>>>>>>>>>
>>>>>>>>> @@ -158,9 +159,10 @@ SYM_CODE_START(kvm_exc_entry)
>>>>>>>>> csrwr t0, LOONGARCH_CSR_GTLBC
>>>>>>>>> ld.d tp, a2, KVM_ARCH_HTP
>>>>>>>>> ld.d sp, a2, KVM_ARCH_HSP
>>>>>>>>> + UNWIND_HINT_REGS
>>>>>>>>> +
>>>>>>>>> /* restore per cpu register */
>>>>>>>>> ld.d u0, a2, KVM_ARCH_HPERCPU
>>>>>>>>> - addi.d sp, sp, -PT_SIZE
>>>>>>>>>
>>>>>>>>> /* Prepare handle exception */
>>>>>>>>> or a0, s0, zero
>>>>>>>>> @@ -184,10 +186,11 @@ SYM_CODE_START(kvm_exc_entry)
>>>>>>>>> csrwr s1, KVM_VCPU_KS
>>>>>>>>> kvm_switch_to_guest
>>>>>>>>>
>>>>>>>>> + UNWIND_HINT_UNDEFINED
>>>>>>>>> ret_to_host:
>>>>>>>>> - ld.d a2, a2, KVM_ARCH_HSP
>>>>>>>>> - addi.d a2, a2, -PT_SIZE
>>>>>>>>> - kvm_restore_host_gpr a2
>>>>>>>>> + ld.d sp, a2, KVM_ARCH_HSP
>>>>>>>>> + kvm_restore_host_gpr sp
>>>>>>>>> + addi.d sp, sp, PT_SIZE
>>>>>>>>> jr ra
>>>>>>>>>
>>>>>>>>> SYM_INNER_LABEL(kvm_exc_entry_end, SYM_L_LOCAL)
>>>>>>>>> @@ -200,11 +203,15 @@ SYM_CODE_END(kvm_exc_entry)
>>>>>>>>> * a0: kvm_run* run
>>>>>>>>> * a1: kvm_vcpu* vcpu
>>>>>>>>> */
>>>>>>>>> -SYM_FUNC_START(kvm_enter_guest)
>>>>>>>>> +SYM_CODE_START(kvm_enter_guest)
>>>>>>>>> + UNWIND_HINT_UNDEFINED
>>>>>>>>> /* Allocate space in stack bottom */
>>>>>>>>> - addi.d a2, sp, -PT_SIZE
>>>>>>>>> + addi.d sp, sp, -PT_SIZE
>>>>>>>>> /* Save host GPRs */
>>>>>>>>> - kvm_save_host_gpr a2
>>>>>>>>> + kvm_save_host_gpr sp
>>>>>>>>> + la.pcrel a2, 111f
>>>>>>>>> + st.d a2, sp, PT_ERA
>>>>>>>>> + UNWIND_HINT_REGS
>>>>>>>>>
>>>>>>>> why the label 111f is more accurate? Supposing there is hw
>>>>>>>> breakpoint here and backtrace is called, what is the call trace
>>>>>>>> stack then? obvious label 111f is not executed instead.
>>>>>>> Xianglai said marking it as regs can get more stack infos, so I use
>>>>>>> UNWIND_HINT_REGS marked here, though it not called. Remove
>>>>>>> UNWIND_HINT_REGS thenforbid unwind from here.
>>>>>>> This function is called and should usually be marked as "call",
>>>>>>> but it is complex by switching the stack and use `ertn` calls
>>>>>>> another function.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> UNWIND_HINT_REGS is used for nested kernel stack, is that right?
>>>>>>>> With nested interrupt and exception handlers on LoongArch kernel, is
>>>>>>>> UNWIND_HINT_REGS used?
>>>>>>>>
>>>>>>>> SYM_CODE_START(ret_from_fork_asm)
>>>>>>>> UNWIND_HINT_REGS
>>>>>>>> move a1, sp
>>>>>>>> bl ret_from_fork
>>>>>>>> STACKLEAK_ERASE
>>>>>>>> RESTORE_STATIC
>>>>>>>> RESTORE_SOME
>>>>>>>> RESTORE_SP_AND_RET
>>>>>>>> SYM_CODE_END(ret_from_fork_asm)
>>>>>>>> With this piece of code, what is contents of pt_regs? In generic it
>>>>>>>> is called from sys_clone, era is user PC address, is that right? If so,
>>>>>>>> what is detailed usage in the beginning of ret_from_fork_asm?
>>>>>>> The stacktrace shows the control flow where the PC will go back, so
>>>>>>> it is right because when PC is in ret_from_fork_asm, it is already
>>>>>>> another thread. The era means it will go back user mode.
>>>>>> The problem is that user mode era shows unwind with error, and
>>>>>> user_mode(regs) is not accurate. here is piece of code.
>>>>>> pc = regs->csr_era;
>>>>>> if (!__kernel_text_address(pc))
>>>>>> goto err;
>>>>>> will UNWIND_HINT_END_OF_STACK be better than UNWIND_HINT_REGS?
>>>>>
>>>>> You are right. And the reason why current the unwinder does not cause
>>>>> error is in case ORC_TYPE_REGS we process it by user_mode(regs).
>>>> Any process about UNWIND_HINT_REGS usage, is nested exception unwind
>>>> supported now?
>>>>
>>>> Talking without any actions seems not be style of Loongson :)
>>> From my point of view, Tiezhu's simple solution is acceptable...
>> is nested exception/interrupt unwind supported now? IIRC only nested
>> interrupt with stack switch is supported, nested exception/interrupt
>> unwind without stack switch is not supported. Is that right?
> Nested exception is supported, but it doesn't switch stack; only
> interrupt need switch stack.
yes, you are right. Nested exception is supported, UNWIND_HINT_REGS() is
used in SAVE_SOME() macro.
Regards
Bibo Mao
>
>
> Huacai
>
>>
>> Regards
>> Bibo Mao
>>
>>>
>>> Huacai
>>>
>>>>
>>>> Regards
>>>> Bibo Mao
>>>>>
>>>>> Jinyang
>>>>>
>>>>
>>
next prev parent reply other threads:[~2026-04-13 3:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-27 1:27 [PATCH V3 0/2] LoongArch: KVM: fix "unreliable stack" issue Xianglai Li
2025-12-27 1:27 ` [PATCH V3 1/2] LoongArch: KVM: Compile the switch.S file directly into the kernel Xianglai Li
2025-12-27 1:27 ` [PATCH V3 2/2] LoongArch: KVM: fix "unreliable stack" issue Xianglai Li
2025-12-27 12:49 ` Huacai Chen
2025-12-29 1:53 ` lixianglai
2025-12-28 13:32 ` Jinyang He
2025-12-29 3:53 ` lixianglai
2025-12-29 7:10 ` Jinyang He
2025-12-29 8:50 ` Bibo Mao
2025-12-29 10:11 ` lixianglai
2025-12-29 10:41 ` Jinyang He
2025-12-30 1:18 ` Bibo Mao
2025-12-30 2:13 ` Huacai Chen
2025-12-30 2:24 ` Bibo Mao
2025-12-30 3:36 ` Jinyang He
2025-12-30 4:03 ` Bibo Mao
2025-12-30 5:53 ` Jinyang He
2025-12-30 6:18 ` Bibo Mao
2026-04-08 1:23 ` Bibo Mao
2026-04-11 14:24 ` Huacai Chen
2026-04-13 0:58 ` Bibo Mao
2026-04-13 3:11 ` Huacai Chen
2026-04-13 3:56 ` Bibo Mao [this message]
2025-12-30 7:22 ` Bibo Mao
2025-12-31 1:11 ` lixianglai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1c542bd9-1e76-fd30-8a26-ed3ab0d965c9@loongson.cn \
--to=maobibo@loongson.cn \
--cc=charlie@rivosinc.com \
--cc=chenhuacai@kernel.org \
--cc=hejinyang@loongson.cn \
--cc=kernel@xen0n.name \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lixianglai@loongson.cn \
--cc=loongarch@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=yangtiezhu@loongson.cn \
--cc=zhaotianrui@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).