| Message ID | 20200521181403.6078-1-git@xen0n.name (mailing list archive) |
|---|---|
| Headers | show |
| Series | CPUCFG emulation on older Loongson64 cores | expand |
Sorry for late reponse. I just want to know how to solve compatibility on older kernel. It is ok to run user application with cpucfg instr on new kernel with this patch, however what if the application is running on older kernel without cpucfg simulation? regards bibo,mao > -----原始邮件----- > 发件人: "WANG Xuerui" <git@xen0n.name> > 发送时间: 2020-05-22 02:14:02 (星期五) > 收件人: linux-mips@vger.kernel.org > 抄送: "WANG Xuerui" <git@xen0n.name> > 主题: [PATCH v3 0/1] CPUCFG emulation on older Loongson64 cores > > This patch brings the CPUCFG instruction to older Loongson64 cores, > enabling a unified way to query processor characteristics on Loongson64 > systems. Previous question of how to best integrate machtype-specific > and machtype-agnostic cpu probe logic is resolved. (thanks Thomas for > reviewing!) > > Tested on Loongson-3A3000. > > Also, to aid userspace in determining CPUCFG availability without having > to handle SIGILL or parse /proc/cpuinfo, a new HWCAP flag is to be added > in a later patch. I am waiting for consensus before implementing this, > as it would be part of userspace ABI. > > v3: > - Fixed build on !CONFIG_MACH_LOONGSON64 > - Refactored to minimize intrusion to machtype-agnostic cpu probe logic > - Minor tweaks to comment and Kconfig wording > - Dropped Reviewed-by and Tested-by from Jiaxun as the code is > refactored significantly > > v2: > - Fixed one more typo in loongson_regs.h > - Merged simulate_loongson3_csr and simulate_loongson3_csr_cpucfg into > one (simulate_loongson3_cpucfg), per Huacai's suggestion > > WANG Xuerui (1): > MIPS: emulate CPUCFG instruction on older Loongson64 cores > > arch/mips/Kconfig | 12 + > arch/mips/include/asm/cpu-info.h | 9 + > .../include/asm/mach-loongson64/cpucfg-emul.h | 65 ++++++ > arch/mips/kernel/cpu-probe.c | 9 + > arch/mips/kernel/traps.c | 45 ++++ > arch/mips/loongson64/Makefile | 1 + > arch/mips/loongson64/cpucfg-emul.c | 217 ++++++++++++++++++ > 7 files changed, 358 insertions(+) > create mode 100644 arch/mips/include/asm/mach-loongson64/cpucfg-emul.h > create mode 100644 arch/mips/loongson64/cpucfg-emul.c > > -- > 2.21.0 </git@xen0n.name></git@xen0n.name>
于 2020年5月22日 GMT+08:00 下午8:06:01, "毛碧波" <maobibo@loongson.cn> 写到: >Sorry for late reponse. >I just want to know how to solve compatibility on older kernel. >It is ok to run user application with cpucfg instr on new kernel with this >patch, however what if the application is running on older kernel without >cpucfg simulation? Application can firstly probe if CPUCFG is supported by kernel & hardware by fork a thread and catch SIGILL signal or HWCAP. Then decide use legacy methods or CPUCFG to probe other features. Similar method have been proofed on Arm.
> -----原始邮件----- > 发件人: "Jiaxun Yang" <jiaxun.yang@flygoat.com> > 发送时间: 2020-05-22 20:57:33 (星期五) > 收件人: "毛碧波" <maobibo@loongson.cn>, "WANG Xuerui" <git@xen0n.name> > 抄送: linux-mips@vger.kernel.org > 主题: Re: [PATCH v3 0/1] CPUCFG emulation on older Loongson64 cores > > > > 于 2020年5月22日 GMT+08:00 下午8:06:01, "毛碧波" <maobibo@loongson.cn> 写到: > >Sorry for late reponse. > >I just want to know how to solve compatibility on older kernel. > >It is ok to run user application with cpucfg instr on new kernel with this > >patch, however what if the application is running on older kernel without > >cpucfg simulation? > > Application can firstly probe if CPUCFG is supported by kernel & hardware > by fork a thread and catch SIGILL signal or HWCAP. > Then decide use legacy methods or CPUCFG to probe other features. > > Similar method have been proofed on Arm. Sure, if that works, what is the purpose of this patch? Do we need cpucfg simulation on older machine since there is proper method already? > -- > Jiaxun Yang </maobibo@loongson.cn></git@xen0n.name></maobibo@loongson.cn></jiaxun.yang@flygoat.com>
于 2020年5月22日 GMT+08:00 下午10:14:02, "毛碧波" <maobibo@loongson.cn> 写到: > > > >> -----原始邮件----- >> 发件人: "Jiaxun Yang" <jiaxun.yang@flygoat.com> >> 发送时间: 2020-05-22 20:57:33 (星期五) >> 收件人: "毛碧波" <maobibo@loongson.cn>, "WANG Xuerui" <git@xen0n.name> >> 抄送: linux-mips@vger.kernel.org >> 主题: Re: [PATCH v3 0/1] CPUCFG emulation on older Loongson64 cores >> >> >> >> 于 2020年5月22日 GMT+08:00 下午8:06:01, "毛碧波" <maobibo@loongson.cn> 写到: >> >Sorry for late reponse. >> >I just want to know how to solve compatibility on older kernel. >> >It is ok to run user application with cpucfg instr on new kernel with this >> >patch, however what if the application is running on older kernel without >> >cpucfg simulation? >> >> Application can firstly probe if CPUCFG is supported by kernel & hardware >> by fork a thread and catch SIGILL signal or HWCAP. >> Then decide use legacy methods or CPUCFG to probe other features. >> >> Similar method have been proofed on Arm. >Sure, if that works, what is the purpose of this patch? Do we need cpucfg >simulation on older machine since there is proper method already? Because it's more efficient and elegant. Also applications can assume systems without CPUCFG have no Loongson extension support. That can save hundreds lines in various applications. We can kill ugly probe method in applications when all machine have upgraded kernel. And as you can see, cpucfg is exporting more config options than any existing methods like HWCAP or cpuinfo. And they may valuable to applications. Btw: Please fix your email client. Thanks.
On 05/22/2020 10:34 PM, Jiaxun Yang wrote: > > > 于 2020年5月22日 GMT+08:00 下午10:14:02, "毛碧波" <maobibo@loongson.cn> 写到: >> >> >> >> > -----原始邮件----- >> > 发件人: "Jiaxun Yang" <jiaxun.yang@flygoat.com> >> > 发送时间: 2020-05-22 20:57:33 (星期五) >> > 收件人: "毛碧波" <maobibo@loongson.cn>, "WANG Xuerui" <git@xen0n.name> >> > 抄送: linux-mips@vger.kernel.org >> > 主题: Re: [PATCH v3 0/1] CPUCFG emulation on older Loongson64 cores >> > >> > >> > >> > 于 2020年5月22日 GMT+08:00 下午8:06:01, "毛碧波" <maobibo@loongson.cn> 写到: >> > >Sorry for late reponse. >> > >I just want to know how to solve compatibility on older kernel. >> > >It is ok to run user application with cpucfg instr on new kernel with this >> > >patch, however what if the application is running on older kernel without >> > >cpucfg simulation? >> > >> > Application can firstly probe if CPUCFG is supported by kernel & hardware >> > by fork a thread and catch SIGILL signal or HWCAP. >> > Then decide use legacy methods or CPUCFG to probe other features. >> > >> > Similar method have been proofed on Arm. >> Sure, if that works, what is the purpose of this patch? Do we need cpucfg >> simulation on older machine since there is proper method already? > > Because it's more efficient and elegant. > Also applications can assume systems without CPUCFG have > no Loongson extension support. > That can save hundreds lines in various applications. You can add add this to hwcap/cpuinfo though it is difficult to add vendor specific hwcap. Application can check hwcap and then use cpucfg gracefully. I do not see usage of cpucfg simulation on older machine, do we add new instruction emulation if there is new instruction? On the other way is there cpuid simulation on x86 system? > > We can kill ugly probe method in applications when all > machine have upgraded kernel. I doubt application vendor has the willing of removing so-called ugly code but work broken on older kernel. > > And as you can see, cpucfg is exporting more config options than any > existing methods like HWCAP or cpuinfo. > And they may valuable to applications. > > Btw: Please fix your email client. > > Thanks. >
于 2020年5月23日 GMT+08:00 上午10:10:16, maobibo <maobibo@loongson.cn> 写到: > > >On 05/22/2020 10:34 PM, Jiaxun Yang wrote: >> >> >> 于 2020年5月22日 GMT+08:00 下午10:14:02, "毛碧波" <maobibo@loongson.cn> 写到: >>> >>> >>> >>> > -----原始邮件----- >>> > 发件人: "Jiaxun Yang" <jiaxun.yang@flygoat.com> >>> > 发送时间: 2020-05-22 20:57:33 (星期五) >>> > 收件人: "毛碧波" <maobibo@loongson.cn>, "WANG Xuerui" <git@xen0n.name> >>> > 抄送: linux-mips@vger.kernel.org >>> > 主题: Re: [PATCH v3 0/1] CPUCFG emulation on older Loongson64 cores >>> > >>> > >>> > >>> > 于 2020年5月22日 GMT+08:00 下午8:06:01, "毛碧波" <maobibo@loongson.cn> 写到: >>> > >Sorry for late reponse. >>> > >I just want to know how to solve compatibility on older kernel. >>> > >It is ok to run user application with cpucfg instr on new kernel with this >>> > >patch, however what if the application is running on older kernel without >>> > >cpucfg simulation? >>> > >>> > Application can firstly probe if CPUCFG is supported by kernel & hardware >>> > by fork a thread and catch SIGILL signal or HWCAP. >>> > Then decide use legacy methods or CPUCFG to probe other features. >>> > >>> > Similar method have been proofed on Arm. >>> Sure, if that works, what is the purpose of this patch? Do we need cpucfg >>> simulation on older machine since there is proper method already? >> >> Because it's more efficient and elegant. >> Also applications can assume systems without CPUCFG have >> no Loongson extension support. >> That can save hundreds lines in various applications. >You can add add this to hwcap/cpuinfo though it is difficult to add vendor specific >hwcap. Application can check hwcap and then use cpucfg gracefully. > >I do not see usage of cpucfg simulation on older machine, do we add new instruction emulation if there is new instruction? On the other way is there cpuid simulation on x86 system? No. But trap and emulate unsupported feature is usual for other architecture. Almost all existing x86 processors have hardware cpuid implementation. That will also happen on Loongson someday, we're preparing for that day. > >> >> We can kill ugly probe method in applications when all >> machine have upgraded kernel. >I doubt application vendor has the willing of removing so-called ugly code but work broken >on older kernel. Nobody here cares vendor. We can only provide limited support to non-FOSS application vendor. We're trying to reduce maintainance overhead for other projects, Loongson's business concern is out of our scope. We're also trying to let applications compiled for general MIPS can also benefit from Loongson's extension without troubling upstream too much. We can still ensure the whole thing works on older kernel. Just can't probe Loongson features correctly. The whole proposal is just because Loongson even failed to establish a stable interface for application to probe features. Neither cpuinfo nor HWCAP is currently utilized by Loongson (Probably in close-source kernel but that's also out of our scope). Also bit domain of HWCAP is limited, we don't want to see Loongson occupy too much general MIPS resources, and CPUCFG can provide unlimited config options. So we decided to emulate CPUCFG instead of deliver them in HWCAP. Thanks. > >> >> And as you can see, cpucfg is exporting more config options than any >> existing methods like HWCAP or cpuinfo. >> And they may valuable to applications. >> >> Btw: Please fix your email client. >> >> Thanks. >> >
On 5/23/20 10:10 AM, maobibo wrote: > > On 05/22/2020 10:34 PM, Jiaxun Yang wrote: >> >> 于 2020年5月22日 GMT+08:00 下午10:14:02, "毛碧波" <maobibo@loongson.cn> 写到: >>> >>> >>> > -----原始邮件----- >>> > 发件人: "Jiaxun Yang" <jiaxun.yang@flygoat.com> >>> > 发送时间: 2020-05-22 20:57:33 (星期五) >>> > 收件人: "毛碧波" <maobibo@loongson.cn>, "WANG Xuerui" <git@xen0n.name> >>> > 抄送: linux-mips@vger.kernel.org >>> > 主题: Re: [PATCH v3 0/1] CPUCFG emulation on older Loongson64 cores >>> > >>> > >>> > >>> > 于 2020年5月22日 GMT+08:00 下午8:06:01, "毛碧波" <maobibo@loongson.cn> 写到: >>> > >Sorry for late reponse. >>> > >I just want to know how to solve compatibility on older kernel. >>> > >It is ok to run user application with cpucfg instr on new kernel with this >>> > >patch, however what if the application is running on older kernel without >>> > >cpucfg simulation? >>> > >>> > Application can firstly probe if CPUCFG is supported by kernel & hardware >>> > by fork a thread and catch SIGILL signal or HWCAP. >>> > Then decide use legacy methods or CPUCFG to probe other features. >>> > >>> > Similar method have been proofed on Arm. >>> Sure, if that works, what is the purpose of this patch? Do we need cpucfg >>> simulation on older machine since there is proper method already? >> Because it's more efficient and elegant. >> Also applications can assume systems without CPUCFG have >> no Loongson extension support. >> That can save hundreds lines in various applications. > You can add add this to hwcap/cpuinfo though it is difficult to add vendor specific > hwcap. Application can check hwcap and then use cpucfg gracefully. We only have so much HWCAP bits left, plus it is common to all MIPS. Due to fragmentation in the MIPS world, most of Loongson feature bits would be useless to others, yet still taking up precious bits. > > I do not see usage of cpucfg simulation on older machine, do we add new instruction emulation if there is new instruction? On the other way is there cpuid simulation on x86 system? New instructions typically are not emulated FWIW. They exist for a purpose, that is, accelerate certain domain-specific workloads; trap-and-emulate invariably devastates performance. But CPUCFG is a different story. It is similar to CPUID, which is to be called sparingly but deliver significant value to software. Hence back-fitting almost all Loongson processors relevant today with CPUCFG is beneficial to a unified feature detection approach IMO. As for CPUID on x86, it is not emulated, because: (1) it is possible to determine its presence without executing potentially invalid instruction (toggling FLAGS to see if one particular bit is preserved); (2) it is present since later 486 and Pentium, which covers practically all x86 in use today. > >> We can kill ugly probe method in applications when all >> machine have upgraded kernel. > I doubt application vendor has the willing of removing so-called ugly code but work broken > on older kernel. We are platform builders. We are not in a position to control, or to put it bluntly, dictate, what ISVs do or not do. Not removing the code is okay, it will not break anything, and (closed-source) apps like this simply gradually die out along with the legacy hardware. >> And as you can see, cpucfg is exporting more config options than any >> existing methods like HWCAP or cpuinfo. >> And they may valuable to applications. >> >> Btw: Please fix your email client. >> >> Thanks. >>
On 2020/5/22 20:06, 毛碧波 wrote: > Sorry for late reponse. > I just want to know how to solve compatibility on older kernel. > It is ok to run user application with cpucfg instr on new kernel with this > patch, however what if the application is running on older kernel without > cpucfg simulation? Hi Bibo, A bit of detailed analysis is always good, so here we go: 1. Application targeting old kernels. These applications never have guaranteed CPUCFG availability to begin with, nor will they ever have. So they simply parse /proc/cpuinfo or do CPUCFG while handling SIGILL. This will work on all kernels, so no problem. 2. Application targeting upstream kernel. First, let's pretend Loongson-1 and Loongson-2EF do not exist. Then *all* Loongson have CPUCFG. It's basically like going back in time and retro-fitting all legacy chips sold with the new instruction, but only with newer kernels. Then we have: 2a. Applications that still want to run on old kernels; 2b. Applications that simply don't care and just go ahead to invoke CPUCFG. For case 2a, the developers always realize they actually belong to case 1, sooner or later. Typically after seeing the first customer bug report and deciding that the compatibility is required. For case 2b, indeed such applications will break on the moment they encounter a legacy kernel, but it does not matter. Very likely there is no such possibility to begin with; but even if such a situation does happen, it is the *downstream developers* making the decision to rely on newer kernels to "blame". It is not acceptable to stagnate development, just because someone decides to not update their software. All legacy hardware and software die eventually, and those that remain probably do not receive updates, so they are irrelevant to this discussion either. P.S.: please kindly fix your email client, it is mangling the block quotes, apparently HTML-escaping the characters. And please don't top-post while you're at it... > regards > bibo,mao