[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7ddd6efc-e7ad-b2f8-9a4d-5ca1cad9e74d@loongson.cn>
Date: Thu, 27 Nov 2025 09:53:06 +0800
From: Bibo Mao <maobibo@...ngson.cn>
To: Tiezhu Yang <yangtiezhu@...ngson.cn>, Jinyang He <hejinyang@...ngson.cn>
Cc: Huacai Chen <chenhuacai@...nel.org>, Xi Zhang <zhangxi@...inos.cn>,
Xianglai Li <lixianglai@...ngson.cn>, loongarch@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] LoongArch: Handle special PC in unwind_next_frame()
On 2025/11/27 上午9:39, Tiezhu Yang wrote:
> On 2025/11/26 下午5:56, Bibo Mao wrote:
>>
>>
>> On 2025/11/26 下午5:09, Tiezhu Yang wrote:
>>> Cc: Bibo Mao <maobibo@...ngson.cn>
> ...
>>> +#if IS_ENABLED(CONFIG_KVM)
>>> +void (*get_kvm_entry_info)(unsigned long *old, unsigned long *new,
>>> unsigned long *size);
>>> +EXPORT_SYMBOL_GPL(get_kvm_entry_info);
>>> +#endif
>> this method mixes kvm and unwind components and it is obvious hack
>> method. If there are other modules which have the similar problem, how
>> to handle it? Add get_MODULE_1_entry_info/get_MODULE_2_entry_info API :)
>
> Currently, there is no other similar issue and something that should not
> happen in the future, this is "concrete question concrete analysis" and
> "handle special cases with special methods".
If so, I can think LoongArch unwind method is nasty. If this method is
special for KVM module. KVM prefer to compile the exception function
with built-in method, rather than using this nasty method.
Just be curious, it is the same orc unwind method. why is clean with
file arch/x86/kernel/unwind_orc.c, however there is special handling
bt_address() in file arch/loongarch/kernel/unwind_orc.c ?
>
>> KVM module copy exception function to allocated memory, it breaks
>> unwind rules. KVM can compile exception function in kernel and do not
>> copy the exception functions or LoongArch kernel provides unwind hint
>> APIs to handle it.
>
> That is better if it is possible for KVM, no general API for kernel IMO.
>
>>> static inline unsigned long bt_address(unsigned long ra)
> ...
>>> + get_kvm_entry_info = kvm_entry_info;
>> Is this API get_kvm_entry_info() general for all modules or kernel
>> components?
>
> No, it is just to get the necessary exception info for this special KVM
> case, we can use something like EXPORT_SYMBOL_FOR_KVM_INTERNAL to avoid
> the potential misuse if possible (not tested yet).
>
> Thanks,
> Tiezhu
Powered by blists - more mailing lists