多谢增凯，接下来我们会根据TC会议的思路逐步提交SPR剩余的PR到OLK-5.10。还麻烦各位帮忙review。
Thanks,
Jun Tian
From: Zhengzengkai <zhengzengkai@huawei.com>
Sent: Wednesday, October 26, 2022 2:36 PM
To: Tian, Jun J <jun.j.tian@intel.com>; Zhoukang (A) <zhoukang7@huawei.com>; kernel <kernel@openeuler.org>
Cc: Xiexiuqi <xiexiuqi@huawei.com>; Zeng, Jason <jason.zeng@intel.com>; Wang, Lin X <lin.x.wang@intel.com>; Dukaitian (Dukaitian, Intelligent Computing R&D) <dukaitian@huawei.com>; Huxinwei <huxinwei@huawei.com>; Hushiyuan <hushiyuan@huawei.com>; Xuhanbing
<xuhanbing@huawei.com>
Subject: 答复: [PATCH openEuler-5.10 0/4] Try to fix kabi change caused by Intel AMX
Hi 田俊，
附件为TC例会KABI修复建议评估材料
请查收。
谢谢！
发件人: Tian, Jun J [mailto:jun.j.tian@intel.com]
发送时间: 2022年10月25日 10:43
收件人: Zhengzengkai <zhengzengkai@huawei.com>; Zhoukang (A) <zhoukang7@huawei.com>; kernel <kernel@openeuler.org>
抄送: Xiexiuqi <xiexiuqi@huawei.com>; Zeng, Jason <jason.zeng@intel.com>; Wang, Lin X <lin.x.wang@intel.com>;
Dukaitian (Dukaitian, Intelligent Computing R&D) <dukaitian@huawei.com>; Huxinwei <huxinwei@huawei.com>; Hushiyuan <hushiyuan@huawei.com>;
Xuhanbing <xuhanbing@huawei.com>
主题: RE: [PATCH openEuler-5.10 0/4] Try to fix kabi change caused by Intel AMX
KABI的问题主要还是在openEuler LTS update上合入新平台的策略问题。目前openEuler正在快速引入各类多样性平台和完善各平台生态，合入大型的主流新平台很难避免大量的KABI
change。在这个前提下更多的应该是检视KABI change是否影响到第三方module，即使有影响的相关module能否适配KABI的变化。KABI的严格要求也是为了避免这类问题发生，但类似fpu,
task_thread这种内核底层的修改很少会被driver module引用，如果openEuler检视的结果是没有发现类似的兼容问题，同时其他主流OSV已经合并而且暂时也没有类似的问题，那应该有一个策略来决定是否引入对应的平台的KABI的变化。
另外通过宏来规避检查工具或者通过修改现有patch的实现来统一KABI都不是理想的解决办法。修改patch实现来保持KABI的一致也会造成当前openEuler的base和kernel
upstream以及其他主流的OSV的代码存在差异性，对未来rebase或者kernel
upgrade会造成conflict的问题，对通用的三方module的维护也可能有潜在问题。实际上大量加入__GENKSYMS__宏也会造成未来维护和rebase的负担。
所以这个问题的本质是需要大家探讨出相应的策略，并建立一套评估流程，在保证KABI稳定的前提下也能灵活的支持更广泛的平台和生态。
Thanks,
Jun Tian
From: Zhengzengkai <zhengzengkai@huawei.com>
Sent: Monday, October 24, 2022 7:06 PM
To: Tian, Jun J <jun.j.tian@intel.com>; Zhoukang (A) <zhoukang7@huawei.com>; kernel <kernel@openeuler.org>
Cc: Xiexiuqi <xiexiuqi@huawei.com>; Zeng, Jason <jason.zeng@intel.com>; Wang, Lin X <lin.x.wang@intel.com>; Dukaitian (Dukaitian,
Intelligent Computing R&D) <dukaitian@huawei.com>; Huxinwei <huxinwei@huawei.com>; Hushiyuan <hushiyuan@huawei.com>; Xuhanbing <xuhanbing@huawei.com>
Subject: RE: [PATCH openEuler-5.10 0/4] Try to fix kabi change caused by Intel AMX
不建议所有的KABI变更（不论是否SPR相关的补丁）都用直接加__GENKSYMS__宏的方式规避KABI变更。
这组补丁的意图是想让Intel一起评估下这样改的收益和风险，说白了是否值得？
或者说有没有更好的思路？
郑增凯 Zheng Zengkai
Mobile: +86-50000020998(For Welink,eSpace Calls)
Email: zhengzengkai@huawei.com
发件人：Tian, Jun J <jun.j.tian@intel.com>
收件人：Zhoukang (A) <zhoukang7@huawei.com>;Zhengzengkai <zhengzengkai@huawei.com>;kernel
<kernel@openeuler.org>
抄 送：Xiexiuqi <xiexiuqi@huawei.com>;Zeng,
Jason <jason.zeng@intel.com>;Wang, Lin X <lin.x.wang@intel.com>;Dukaitian (Dukaitian, Intelligent Computing R&D) <dukaitian@huawei.com>;Huxinwei
<huxinwei@huawei.com>;Hushiyuan <hushiyuan@huawei.com>;Xuhanbing <xuhanbing@huawei.com>
时 间：2022-10-24 15:42:04
主 题：RE: [PATCH openEuler-5.10 0/4] Try to fix kabi change caused
by Intel AMX
目前看为了统一KABI的检查，最好还是利用__GENKSYMS__包含对应已有修改的kernel
struct和ABI。
这样防止SPR代码合并后check-kabi持续误报的问题，我们也会对SPR相应的KABI
change的部分统一
通过这个方式处理以保持一致。当然前提是大家已经审视过SPR相应change并没有被引用或者影响可控。
修改KABI CRC工具未来也可能造成其他潜在问题，比如不参与checksum检查的KABI未来可能有
第三方module会引用。
Thanks,
Jun Tian
> -----Original Message-----
> From: Zhoukang (A) <zhoukang7@huawei.com>
> Sent: Saturday, October 22, 2022 3:54 PM
> To: Zhengzengkai <zhengzengkai@huawei.com>;
kernel@openeuler.org
> Cc: Xiexiuqi <xiexiuqi@huawei.com>; Zeng, Jason <jason.zeng@intel.com>;
> Wang, Lin X <lin.x.wang@intel.com>; Tian, Jun J <jun.j.tian@intel.com>;
> Dukaitian (Dukaitian, Intelligent Computing R&D) <dukaitian@huawei.com>;
> Huxinwei <huxinwei@huawei.com>; Hushiyuan <hushiyuan@huawei.com>;
> Xuhanbing <xuhanbing@huawei.com>
> Subject: RE: [PATCH openEuler-5.10 0/4] Try to fix kabi change caused by Intel
> AMX
>
> 代码注释有点少,
无法体现KABI兼容思路与驱动的使用约束;
>
> 兼容补丁基于下面设计约束进行设计:
> 内核KABI白名单主要是为第3方驱动提供稳定的运行环境;
因此fpu,
> task_thread, 中断数据结构内部成员,
禁止驱动代码使用;
已经排查过driver
> 目录确实没有驱动使用的情况;
> 基于上面约束,
因此当前fix kabi的补丁仅是避免了检查工具的误报;
>
>
> 另外一种解决思路:
> 直接修改kabi CRC计算工具,
将特定数据结构的CRC值清除;
同时需要在编
> 译阶段检查驱动没有使用特定的数据结构成员;
>
>
>
>
>
> -----Original Message-----
> From: Zhengzengkai
> Sent: Saturday, October 22, 2022 3:39 PM
> To: kernel@openeuler.org
> Cc: Xiexiuqi <xiexiuqi@huawei.com>; Zhoukang (A) <zhoukang7@huawei.com>;
> jason.zeng@intel.com;
lin.x.wang@intel.com; jun.j.tian@intel.com; Dukaitian
> (Dukaitian, Intelligent Computing R&D) <dukaitian@huawei.com>; Zhengzengkai
> <zhengzengkai@huawei.com>
> Subject: [PATCH openEuler-5.10 0/4] Try to fix kabi change caused by Intel AMX
>
> These four patches try to avoid or fix kabi change caused by Intel AMX PR:
> https://gitee.com/openeuler/kernel/pulls/58
>
> Zheng Zengkai (4):
> x86: Avoid kabi change caused by adding pkru element in thread_struct
> x86/extable: Avoid kabi change caused by exception table rework
> x86/fpu: Avoid kabi change caused by struct fpu
> mm: Fix kabi change caused by saved_auxv[] in mm_struct for x86_64
>
> arch/x86/include/asm/extable.h | 4 ++++
> arch/x86/include/asm/fpu/types.h | 4 ++++
> arch/x86/include/asm/processor.h | 2 ++
> arch/x86/include/uapi/asm/auxvec.h | 1 +
> include/linux/mm_types.h | 15 +++++++++++++++
> 5 files changed, 26 insertions(+)
>
> --
> 2.20.1