Sign in
Sign up
Explore
Enterprise
Education
Search
Help
Terms of use
About Us
Explore
Enterprise
Education
Gitee Premium
Gitee AI
AI teammates
Sign in
Sign up
Fetch the repository succeeded.
description of repo status
Open Source
>
Other
>
Operation System
&&
Watch
Unwatch
Watching
Releases Only
Ignoring
456
Star
1.7K
Fork
1.9K
GVP
openEuler
/
kernel
Closed
Code
Issues
1271
Pull Requests
980
Wiki
Insights
Pipelines
Service
Quality Analysis
Jenkins for Gitee
Tencent CloudBase
Tencent Cloud Serverless
悬镜安全
Aliyun SAE
Codeblitz
SBOM
DevLens
Don’t show this again
Update failed. Please try again later!
Remove this flag
Content Risk Flag
This task is identified by
as the content contains sensitive information such as code security bugs, privacy leaks, etc., so it is only accessible to contributors of this repository.
[OLK-6.6] arm64支持machine check safe
Done
#I8M74H
Requirement
Tong Tiangen
Opened this issue
2023-12-06 14:16
<!-- #请根据issue的类型在标题右侧下拉框中选择对应的选项（需求、缺陷或CVE等）--> <!-- #请根据issue相关的版本在里程碑中选择对应的节点，若是与版本无关，请选择“不关联里程碑”--> 【特性描述】 内存工艺的提升，提升了内存的性能和容量等，但是内存出错的概率却在增加。内存硬件的可靠性不能进一步提升的或提升有限的情况下，有必要通过软件减少内核因内存UCE错误引起的复位，提升产品可靠性和用户满意度。 ARM通过RAS扩展提升系统的的可靠性、可用性以及可服务器，系统RAS处理需要系统各层次模块(硬件、Firmware、OS、…)协同合作。 OS判断如果是在用户态触发这个硬件内存错误时，处理方式是杀进程。如果是在内核态触发这个硬件错误时，处理方式是kernel panic。在内核态触发硬件内存错误的处理方式是无差别的kernel panic，我们可以分析是否存在场景可以无需panic，从而进一步提升系统可靠性，比如由硬件内存错误引起的后果不是fatal的（仅仅影响相关的用户态进程，那么我们通过杀掉这个用户态进程并且隔离出错的内存页面就可以），那么我们就无需kernel panic。 根据这个思路，我们初步识别到如下场景下在触发硬件错误时的后果不是fatal的，仅仅是影响了某个进程： 1. uaccess 用户态访问，如copy_{from, to}_user, {get, put}_user。 2. cow写时复制。 3. dump_user_range() 以上的这些场景我们可以称之为machine check safe场景，对这些场景的细分处理本质上是一种RAS能力增强。 【特性竞争力】 简要说明特性的竞争力 【硬件架构】 ARM64 【特性约束】 支持ACPI 【涉及仓库】 全路径，包括增量修改和新增仓库 【交付个人/团队】 请明确交付责任人，如果有团队支撑，请一并填写团队信息
<!-- #请根据issue的类型在标题右侧下拉框中选择对应的选项（需求、缺陷或CVE等）--> <!-- #请根据issue相关的版本在里程碑中选择对应的节点，若是与版本无关，请选择“不关联里程碑”--> 【特性描述】 内存工艺的提升，提升了内存的性能和容量等，但是内存出错的概率却在增加。内存硬件的可靠性不能进一步提升的或提升有限的情况下，有必要通过软件减少内核因内存UCE错误引起的复位，提升产品可靠性和用户满意度。 ARM通过RAS扩展提升系统的的可靠性、可用性以及可服务器，系统RAS处理需要系统各层次模块(硬件、Firmware、OS、…)协同合作。 OS判断如果是在用户态触发这个硬件内存错误时，处理方式是杀进程。如果是在内核态触发这个硬件错误时，处理方式是kernel panic。在内核态触发硬件内存错误的处理方式是无差别的kernel panic，我们可以分析是否存在场景可以无需panic，从而进一步提升系统可靠性，比如由硬件内存错误引起的后果不是fatal的（仅仅影响相关的用户态进程，那么我们通过杀掉这个用户态进程并且隔离出错的内存页面就可以），那么我们就无需kernel panic。 根据这个思路，我们初步识别到如下场景下在触发硬件错误时的后果不是fatal的，仅仅是影响了某个进程： 1. uaccess 用户态访问，如copy_{from, to}_user, {get, put}_user。 2. cow写时复制。 3. dump_user_range() 以上的这些场景我们可以称之为machine check safe场景，对这些场景的细分处理本质上是一种RAS能力增强。 【特性竞争力】 简要说明特性的竞争力 【硬件架构】 ARM64 【特性约束】 支持ACPI 【涉及仓库】 全路径，包括增量修改和新增仓库 【交付个人/团队】 请明确交付责任人，如果有团队支撑，请一并填写团队信息
Comments (
1
)
Sign in
to comment
Status
Done
新建
已接纳
已挂起
In Design
In Development
Done
Accepted
Declined
Assignees
Not set
Labels
sig/Kernel
Not set
Projects
Unprojected
Unprojected
Pull Requests
None yet
None yet
Successfully merging a pull request will close this issue.
Branches
No related branch
Branches (
-
)
Tags (
-
)
Planed to start - Planed to end
-
Top level
Not Top
Top Level: High
Top Level: Medium
Top Level: Low
Priority
Not specified
Serious
Main
Secondary
Unimportant
Duration
（hours）
参与者（2）
C
1
https://gitee.com/openeuler/kernel.git
git@gitee.com:openeuler/kernel.git
openeuler
kernel
kernel
Going to Help Center
Search
Git 命令在线学习
如何在 Gitee 导入 GitHub 仓库
Git 仓库基础操作
企业版和社区版功能对比
SSH 公钥设置
如何处理代码冲突
仓库体积过大，如何减小？
如何找回被删除的仓库数据
Gitee 产品配额说明
GitHub仓库快速导入Gitee及同步更新
什么是 Release（发行版）
将 PHP 项目自动发布到 packagist.org
Repository Report
Back to the top
Login prompt
This operation requires login to the code cloud account. Please log in before operating.
Go to login
No account. Register
