CN117170806A - 虚拟机运行稳定性增强的方法、装置、电子设备及介质 - Google Patents

虚拟机运行稳定性增强的方法、装置、电子设备及介质 Download PDF

Info

Publication number
CN117170806A
CN117170806A CN202311121970.2A CN202311121970A CN117170806A CN 117170806 A CN117170806 A CN 117170806A CN 202311121970 A CN202311121970 A CN 202311121970A CN 117170806 A CN117170806 A CN 117170806A
Authority
CN
China
Prior art keywords
virtual machine
target
abnormal
exception
abnormality
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311121970.2A
Other languages
English (en)
Inventor
刘新朋
郭天泽
黄自江
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guoke Chushi Chongqing Software Co ltd
Original Assignee
Guoke Chushi Chongqing Software Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guoke Chushi Chongqing Software Co ltd filed Critical Guoke Chushi Chongqing Software Co ltd
Priority to CN202311121970.2A priority Critical patent/CN117170806A/zh
Publication of CN117170806A publication Critical patent/CN117170806A/zh
Pending legal-status Critical Current

Links

Classifications

    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Debugging And Monitoring (AREA)

Abstract

本公开涉及一种虚拟机运行稳定性增强的方法、装置、电子设备及介质,上述方法包括:在宿主机检测到异常的情况下,确定上述异常会影响的目标虚拟机进程及其对应的目标虚拟机;根据上述异常的异常信息,生成异常通知信号;将上述异常通知信号通过虚拟机管理器注入上述目标虚拟机;由上述目标虚拟机进行异常处理。实现了目标虚拟机在受到异常影响的情况下对异常的感知并在虚拟机所在的操作系统层面进行对应处理,避免由于虚拟机对异常不知情而再次触发程度更为严重的异常所导致的必须结束整个虚拟机的问题,有效增强虚拟机运行的稳定性。

Description

虚拟机运行稳定性增强的方法、装置、电子设备及介质
技术领域
本公开涉及计算机虚拟化技术领域,尤其涉及一种虚拟机运行稳定性增强的方法、装置、电子设备及介质。
背景技术
虚拟化技术是指将硬件物理资源进行逻辑划分并通过资源调度实现物理资源的有效利用。虚拟化技术可广泛应用于数据中心、云计算、网络安全和智能汽车等领域。
发明人发现相关技术中存在以下技术问题:虚拟机所依附的物理资源来源于宿主机,宿主机的运行过程对于虚拟机的资源调度有着至关重要的影响,一般而言,如果宿主机发生硬件错误或者由于某些软件系统发生问题,宿主机会直接结束(kill)掉对应的软件系统或重启软件系统;如果发生问题的或者受到影响的是虚拟机上运行的某些应用,那么宿主机会将整个虚拟机给结束掉,导致虚拟机上正常运行的其他应用也被迫结束,从而影响虚拟机的运行稳定性。
发明内容
为克服相关技术中存在的问题,本公开实施例提供一种虚拟机运行稳定性增强的方法、装置、电子设备及介质。
根据本公开实施例的第一方面,提供一种虚拟机运行稳定性增强的方法。上述方法包括:在宿主机检测到异常的情况下,确定上述异常会影响的目标虚拟机进程及其对应的目标虚拟机;根据上述异常的异常信息,生成异常通知信号;将上述异常通知信号通过虚拟机管理器注入上述目标虚拟机;由上述目标虚拟机进行异常处理。
在一些实施例中,在宿主机检测到异常的情况下,确定上述异常会影响的目标虚拟机进程及其对应的目标虚拟机,包括:确定发生异常的异常物理资源的当前使用状态;在上述当前使用状态表示上述异常物理资源未被虚拟机进程使用的情况下,根据物理资源与虚拟机物理资源之间的映射关系,确定上述异常物理资源对应的异常虚拟机物理资源;将上述异常虚拟机物理资源的待使用进程确定为上述目标虚拟机进程,将上述目标虚拟机进程所属的虚拟机确定为目标虚拟机。
在一些实施例中,上述异常信息包括:发生异常的异常物理资源的对象信息和异常类型。将上述异常通知信号通过虚拟机管理器注入上述目标虚拟机,包括:将包含上述对象信息和异常类型的异常通知信号发送给虚拟机管理器;由上述虚拟机管理器执行与上述异常通知信号对应的目标异常处理函数;其中,上述目标异常处理函数用于根据上述对象信息进行映射处理,得到虚拟机层面的异常对象信息,并将上述异常对象信息和上述异常类型发送给上述目标虚拟机。
在一些实施例中,发生异常的异常物理资源包括以下至少一种:发生UCNA错误类型的异常物理内存页、异常输入输出;上述异常对象信息包括以下至少一种:异常虚拟机物理内存页、异常虚拟输入输出。在上述异常对象信息包括异常虚拟机物理内存页的情况下,由上述目标虚拟机进行异常处理,包括:在上述目标虚拟机中,与上述目标虚拟机进程对应的目标虚拟处理器将已处理结果进行备份,并对上述异常虚拟机物理内存页设置第一已污染标记,上述第一已污染标记用于指示禁止虚拟机进程访问的状态;在上述异常对象信息包括异常虚拟输入输出的情况下,由上述目标虚拟机进行异常处理,包括:在上述目标虚拟机中,与上述目标虚拟机进程对应的目标虚拟处理器将已处理结果进行备份,对上述异常虚拟输入输出的端口设置禁用标记,并执行以下至少一种:对上述异常虚拟输入输出对应的文件系统和磁盘进行错误检查和错误修复、对上述目标虚拟机进程进行问题检查和问题修复。
在一些实施例中,上述异常通知信号为指示UCNA错误类型且为CMCI中断形式的总线通知信号;上述虚拟机管理器为QEMU-KVM架构,QEMU层运行在用户空间,KVM层运行在内核空间。其中,将包含上述对象信息和异常类型的异常通知信号发送给虚拟机管理器,包括:基于上述对象信息,通过反向映射遍历上述异常物理资源影响的目标进程;在遍历每个目标进程的过程中,确定当前目标进程是否为QEMU-KVM类型的进程;在当前目标进程为QEMU-KVM类型的进程的情况下,将上述总线通知信号发送给当前目标进程对应的目标QEMU-KVM层。
在一些实施例中,上述目标异常处理函数包括:用于向虚拟机内核注入UCNA类型错误的异常注入函数。其中,由上述虚拟机管理器执行与上述异常通知信号对应的目标异常处理函数,包括:上述目标QEMU-KVM层调用与上述异常通知信号对应的上述异常注入函数;通过上述异常注入函数构建UCNA错误在虚拟机层面对应的目标MCE异常事件结构体;上述目标MCE异常事件结构体包含上述异常对象信息和上述异常类型;上述异常注入函数基于系统调用的方式将上述目标MEC异常事件结构体注入至上述目标虚拟机的操作系统内核。
在一些实施例中,发生异常的物理资源包括:发生UCNA错误类型的异常物理内存页。上述方法还包括:在宿主机检测到发生UCNA错误类型的异常物理内存页的情况下,宿主机对上述异常物理内存页设置第二已污染标记,上述第二已污染标记用于指示禁止宿主机进程访问的状态;将上述异常物理内存页与对应的虚拟机物理内存页之间的映射关系进行解除;将上述异常物理内存页从物理内存页缓存中删除。
在一些实施例中,上述方法还包括:在宿主机的BIOS SETUP界面中基于RAS配置项进行内存RAS功能的启用设置,包括:设置内存污染(poison)配置项处于启用状态,设置主动巡检(Acitive Scrub)配置项处于启用状态,设置主动巡检周期(Active ScrubInterval)配置项的周期参数值,设置被动巡检(Passive Scrub)配置项处于启用状态,设置校正错误操作(Correct Error handle)配置项中的可纠正错误阈值(Correct ErrorThreshold)、设置校正错误操作配置项中的漏斗周期(Funnel Period)为启用状态和设置校正错误操作配置项中的设备错误预先校正功能(Advance Device Correction)为关闭状态。
根据本公开实施例的第二方面,提供一种虚拟机运行稳定性增强的装置。上述装置包括:确定模块、信号生成模块、异常注入模块和异常处理模块。上述确定模块用于在宿主机检测到异常的情况下,确定上述异常会影响的目标虚拟机进程及其对应的目标虚拟机。上述信号生成模块用于根据上述异常的异常信息,生成异常通知信号。上述异常注入模块用于将上述异常通知信号通过虚拟机管理器注入上述目标虚拟机。上述异常处理模块设置于上述目标虚拟机内,用于进行异常处理。
根据本公开实施例的第三方面,提供一种电子设备,包括:处理器;用于存储处理器可执行指令的存储器;上述处理器,用于从上述存储器中读取上述可执行指令,并执行上述可执行指令以实现本公开第一方面所提供的虚拟机运行稳定性增强的方法。
根据本公开实施例的第四方面,提供一种计算机可读存储介质,其上存储有计算机程序指令,该计算机程序指令被处理器执行时实现本公开第一方面所提供的虚拟机运行稳定性增强的方法。
本公开的实施例提供的技术方案可以包括以下有益效果:
在宿主机检测到异常的情况下,通过确定上述异常会影响的目标虚拟机进程(例如目标虚拟机进程为目标虚拟机中的某个应用程序A,目标虚拟机上运行有很多应用程序,诸如A、B、C和D等)及其对应的目标虚拟机,并根据异常的异常信息生成异常通知信号,通过虚拟机管理器将异常通知信号注入到目标虚拟机,由目标虚拟机进行异常处理,提供了一种在检测到异常后生成异常通知信号并通过虚拟机管理器将异常注入至目标虚拟机,由目标虚拟机对应进行异常处理的方案,各种类型的异常在发生后都能够通过虚拟机管理器将异常通知到目标虚拟机,实现了目标虚拟机在受到异常影响的情况下对异常的感知并在虚拟机所在的操作系统层面进行对应处理,避免由于虚拟机对异常不知情而再次触发程度更为严重的异常所导致的必须结束(kill)整个虚拟机(结束虚拟机意味着其上运行的应用程序A~D都被kill)的问题。因此本公开实施例提供的方案能够避免在异常发生后采用一刀切式方式来结束虚拟机引起的虚拟机系统崩溃的缺陷,有效增强虚拟机运行的稳定性。
例如,针对UCNA类异常而言,能够通过异常注入使得目标虚拟机感知到这类异常并通过在目标虚拟机内的异常处理(例如在虚拟机内隔离对应的被污染页,避免二次访问)而有效避免对被污染的内存页的二次访问,从而有效避免引发更严重的异常类型(例如为SRAO和SRAR异常类型),也就有效避免了宿主机结束掉整个虚拟机所导致的问题,从而增强虚拟机运行的稳定性。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本公开的实施例,并与说明书一起用于解释本公开的原理。
图1是相关技术中关于异常的分类示意图。
图2是根据一示例性实施例示出的虚拟机运行稳定性增强的方法的流程图。
图3是根据一示例性实施例示出的步骤S210的详细实施流程图。
图4是根据一示例性实施例示出的虚拟机运行稳定性增强的方法的实施过程示意图。
图5是根据一示例性实施例示出的运行有虚拟机的电子设备在执行上述虚拟机运行稳定性增强的方法过程中宿主机、虚拟机管理器和虚拟机之间的交互时序图。
图6是根据一示例性实施例示出的虚拟机运行稳定性增强的装置的框图。
图7是根据一示例性实施例示出的电子设备的框图。
具体实施方式
下面将结合附图详细地对示例性实施例进行描述说明。
应当指出,相关实施例及附图仅为描述说明本公开所提供的示例性实施例,而非本公开的全部实施例,也不应理解本公开受相关示例性实施例的限制。
应当指出,本公开中所用术语“第一”、“第二”等仅用于区别不同步骤、设备或模块等。相关术语既不代表任何特定技术含义,也不表示它们之间的顺序或者相互依存关系。
应当指出,本公开中所用术语“一个”、“多个”、“至少一个”的修饰是示意性而非限制性的。除非在上下文另有明确指出,否则应该理解为“一个或多个”。全文中,输入输出含义是输入或输出中的至少一个。
应当指出,本公开中所用术语“和/或”,用于描述关联对象之间的关联关系,一般表示至少存在三种关联关系。例如,A和/或B,至少可以表示:单独存在A,同时存在A和B,单独存在B这三种关联关系。
应当指出,本公开的方法实施例中记载的各个步骤可以按照不同的顺序执行,和/或并行执行。除非特别说明,本公开的范围不受相关实施例中步骤的描述顺序限制。
需要说明的是,本公开中所有获取信号、信息或数据的动作都是在遵照所在地国家相应的数据保护法规政策的前提下,并获得由相应装置所有者给予授权的情况下进行的。
示例性方法
在计算机虚拟化技术中,通过将电子设备的硬件物理资源进行逻辑划分构建虚拟机,并通过资源合理调度,实现物理资源的高效利用。虚拟机也可以视为一个软件系统,虚拟机所依托物理资源的主机称为宿主机,在虚拟机运行过程中,宿主机中软件或硬件的运行状态对于虚拟机有着至关重要的影响。
一般而言,宿主机在运行过程中,会产生各种类型的异常,诸如系统软件异常、应用软件异常、显示异常(例如可能是硬件错误、软件冲突、病毒木马等导致的蓝屏,散热器发生问题或者硬件调试失败等导致黑屏现象)、输入输出(IO)异常、内存异常等。
软件异常(包含系统软件异常或应用软件异常)指的是程序(可以是系统程序或应用程序等)发生了一些意料之外的问题,导致程序无法正常运行的情况。通常,这种异常会导致程序崩溃或者无法执行某些操作。造成软件异常的原因各种各样,诸如:系统文件缺失或损坏、程序组件丢失、代码错误(Code Error)、内存错误(Memory Error)、内存泄漏(Memory Leak,是指程序中已动态分配的堆内存由于某种原因程序未释放或无法释放,造成系统内存的浪费,导致程序运行速度减慢甚至系统崩溃等严重后果)、系统资源不足等。
下面结合图1来介绍各种异常类型。
图1是相关技术中关于异常的分类示意图。
参照图1所示,相关技术中,将异常(Faults或Error,也可以描述为错误、故障等)划分为可检测(Detected)和不可检测(Undetected)两大类。
其中,不可检测(Undetected)的异常是没有办法捕捉到和处理的,一般划分为良性(Benign)类型和严重(Critical)类型,良性类型异常的影响相对较为轻微。严重类型异常的影响较大,又被称作SDC(Silent Data Corruption)类异常。这种Critical类型的异常需要在系统设计的过程中尽量避免或者必须通过优化系统设计来降低这种类型异常的发生率。
可检测(Detected)异常分为可纠正(Corrected)和不可纠正(UC,Un-Corrected)两大类,例如蓝屏现象属于可检测不可纠正类异常。不可纠正错误一般分为可恢复的异常(UCR,Un-Corrected Recoverable)和不可恢复错误(DUE)。
不可恢复的异常包括灾难级别(Catastrophic)或致命级别(Fatal)的不可恢复异常)。
可恢复的异常(UCR)包括UCNA(Un-Corrected No Action required)、SRAO(Software Recoverable Action Optional)和SRAR(Software Recoverable ActionRequired)这三类。这三类异常是提供给系统软件侧可以恢复的异常类型。其中UCNA内存异常发生,表明系统中的一些数据被破坏,但是数据没有被消耗,处理器的状态有效且系统可以继续在这个处理器上继续执行。SRAO内存异常属于选择性处理的异常,可以进行处理或不进行处理。SRAR内存异常属于必须处理的异常。
目前的计算机系统一般都支持RAS(Reliability Availability andServiceability,可靠性可用性和可服务型,确保整个系统尽可能长期可靠的运行而不下线,并且具备足够强大的容错机制)特性,通过CPU提供的MCA(一种硬件检测机制)机制可检测到硬件故障的发生原因,例如内存异常和缓存(Cache)异常、输入输出异常等硬件故障。
发明人在研发中发现相关技术中存在以下技术问题:如果宿主机发生硬件错误或者由于某些软件系统发生问题,宿主机会直接结束(kill)掉对应的软件系统或重启软件系统;如果发生问题的或者受到影响的是虚拟机上运行的某些应用,那么宿主机会将整个虚拟机给结束(kill)掉,导致虚拟机上正常运行的其他应用也被迫结束,从而影响虚拟机的运行稳定性。
此外,宿主机针对一些异常进行处理时,通常对于虚拟机而言是无感的,例如宿主机在面对UCNA类型的异常时,仅会在宿主机层面隔离被污染的内存页;由于相关技术中针对这类异常类型采取的策略是无需处理(No Action),因此这一UCNA类型异常对于虚拟机而言是不知情的,虚拟机的程序在运行中如果用到被污染的内存页,仍然会像往常一样继续去访问到对应的内存页;等到虚拟机的应用程序再次访问被隔离的内存污染页的时候(例如程序代码执行到写入或读取被污染的内存页的数据时),会触发更加严重的异常类型,使得宿主机必须采取结束掉整个虚拟机的处理措施,然而二次触发的结果会导致虚拟机上正常运行的其他应用程序也被迫结束,从而影响虚拟机的运行稳定性。
有鉴于此,本公开的实施例提供了一种虚拟机运行稳定性增强的方法,在宿主机检测到异常的情况下,确定上述异常会影响的目标虚拟机进程及其对应的目标虚拟机;根据上述异常的异常信息,生成异常通知信号;将上述异常通知信号通过虚拟机管理器注入上述目标虚拟机;由上述目标虚拟机进行异常处理。
在宿主机检测到异常的情况下,通过确定上述异常会影响的目标虚拟机进程(例如为目标虚拟机中的某个应用程序A,目标虚拟机上运行有很多应用程序,诸如A、B、C和D等)及其对应的目标虚拟机,并根据异常的异常信息生成异常通知信号,通过虚拟机管理器将异常通知信号注入到目标虚拟机,由目标虚拟机进行异常处理,提供了一种在检测到异常后生成异常通知信号并通过虚拟机管理器将异常注入至目标虚拟机,由目标虚拟机对应进行异常处理的方案。各种类型的异常在发生后都能够通过虚拟机管理器将异常通知到目标虚拟机,实现了目标虚拟机在受到异常影响或引起异常的情况下对异常的感知并在虚拟机所在的操作系统层面进行对应处理,避免由于虚拟机对异常不知情而再次触发程度更为严重的异常所导致的必须结束(kill)整个虚拟机(结束虚拟机意味着其上运行的应用程序A~D都被kill)的问题。因此本公开实施例提供的方案能够避免在异常发生后采用一刀切式方式来结束虚拟机引起的虚拟机系统崩溃的缺陷,有效增强虚拟机运行的稳定性。
例如针对UCNA类内存异常而言,通过异常注入使得目标虚拟机感知到这类异常,并通过在目标虚拟机内的异常处理(例如在虚拟机内隔离对应的被污染页,避免二次访问)而有效避免对被污染的内存页的二次访问,从而有效避免引发更严重的异常类型,也就有效避免了宿主机结束掉整个虚拟机所导致的问题,从而增强虚拟机运行的稳定性。
图2是根据一示例性实施例示出的虚拟机运行稳定性增强的方法的流程图。图4是根据一示例性实施例示出的虚拟机运行稳定性增强的方法的实施过程示意图。图5是根据一示例性实施例示出的运行有虚拟机的电子设备在执行上述虚拟机运行稳定性增强的方法过程中宿主机、虚拟机管理器和虚拟机之间的交互时序图。
参照图2和图5所示,本公开实施例提供的虚拟机运行稳定性增强的方法,包括以下步骤:S210、S220、S230和S240。
上述步骤S210~S240可以由具有运算能力且运行有虚拟机的电子设备执行。
在步骤S210,在宿主机检测到异常的情况下,确定上述异常会影响的目标虚拟机进程及其对应的目标虚拟机。
上述异常包括但不限于是:系统软件异常、应用软件异常、显示异常(例如可能是硬件错误、软件冲突、病毒木马等导致的蓝屏,散热器发生问题或者硬件调试失败等导致黑屏现象)、硬件异常(例如物理内存异常、硬盘异常、输入输出(IO)异常、电源故障、网络故障)等。
在一些实施场景中,一些硬件异常(诸如包含内存异常、输入输出异常等)发生后,可能会对虚拟机进程访问虚拟机物理资源(由物理机的物理资源所进行映射)的过程造成不良影响。
或者,在另一些实施场景中,宿主机上一些系统软件的异常可能也会对虚拟机上运行的某些进程产生不良影响。例如宿主机的内核中某个数据分发的代码出现问题(bug)会引起用于进行数据收发的环形队列出现问题,无法向虚拟机进行数据传输,在虚拟机的应用层面产生应用程序数据丢包的问题。
在一些实施例中,需要提前为宿主机配置进行相关异常处理的能力,例如在执行步骤S210之前,上述方法还包括:在宿主机的BIOS(Basic Input/Output System,是用于设置系统参数的程序)SETUP界面中基于RAS配置项进行内存RAS功能的启用设置。其中,在内存RAS功能的启用设置中可以具体包含针对UCNA类型错误进行处理的能力配置,从而在宿主机检测到相应的异常类型后,能够执行本公开实施例提供的步骤S210~S240对应的异常注入和处理逻辑。
图3是根据一示例性实施例示出的步骤S210的详细实施流程图。
在一些实施例中,参照图3所示,上述步骤S210中,在宿主机检测到异常的情况下,确定上述异常会影响的目标虚拟机进程及其对应的目标虚拟机,包括以下步骤:S310、S320和S330。
在步骤S310,确定发生异常的异常物理资源的当前使用状态。
发生异常的物理资源称为异常物理资源,在一些实施例中,异常物理资源包括但不限于是:发生UCNA类型的异常物理内存页、异常输入输出(IO)等。
在一些实施例中,发生UCNA类型的内存异常,该类异常通常不会通过MCE进行通知,而是按照corrected machine check error的方式报告给系统软件;在UCNA物理内存异常的情况下,异常物理资源的当前使用状态可以是:系统内的某些数据损坏或发生错误,但是这些损坏的数据或错误数据还没有被使用,并且处理器的状态是有效的,所以可能继续正常执行本处理器的代码。针对这种情况,相关技术中采取的策略是:UCNA类型异常不需要系统软件做任何的动作,就可以继续执行。与之不同,本公开的实施例中,针对这种类型的内存异常要进行异常注入至目标虚拟机并在目标虚拟机内采取对应的异常处理措施,其设置目的至少包含:避免由于虚拟机对物理内存异常不知情而导致的对被污染页的二次访问,从而导致引发更严重的异常,例如为MCE类异常,导致宿主机响应于更严重的异常进行处理时采取结束(kill)掉虚拟机的方式,引发虚拟机系统的崩溃和虚拟机上运行的其他正常应用程序的被迫结束。
本公开的实施例中,在发生UCNA类型的物理内存异常后,执行步骤S210~S240,通过异常注入使得目标虚拟机感知到这类异常并通过在目标虚拟机内的异常处理(例如在虚拟机内隔离对应的被污染页,避免二次访问)而有效避免对被污染的内存页的二次访问,从而有效避免引发更严重的异常类型(例如像SRAO或SRAR等类型的MCE异常),也就有效避免了宿主机结束掉整个虚拟机所导致的问题,从而增强虚拟机运行的稳定性。
在其他实施例中,上述异常物理资源也可以包括SRAO和SRAR类型的物理内存异常。
相关技术中,SRAO类型的内存异常一般会通过MCE的方式进行通知,系统可以选择不进行恢复动作,也可以选择进行,不是强制性的。并且不需要从发生MCE的地方继续重新执行。在SRAO物理内存异常的情况下,异常物理资源的当前使用状态可以是:系统中有错误数据,但是错误数据没有被使用,处理器还是处于有效状态。SRAO提供了更多的信息让系统软件进行恢复动作,例如通过在IA32_MCi_STATUS(一种状态信号)的MISCV(一种配置参数项)和ADDRV(另一种配置参数项)设定出错恢复措施,系统软件需要检查IA32_MCi_STATUS的MCAerror code域来找到该SRAO对应的恢复操作。如果MISCV和ADDRV没有被设置的话,一般不进行系统恢复动作,而是继续正常执行。
针对SRAR类型的内存异常,系统软件在调度其他执行进程到本处理器前必须执行一个恢复动作。SRAR类型的内存异常意味着错误被发现了,并且是在执行流程中发现并报告的错误。
在一些实施例中,在宿主机内核检测到SRAR或SRAO类型的内存异常后,宿主机进行相关污染页的标记、以及将存在问题页的虚拟机物理内存与物理内存之间的映射关系进行解除;并在下一次接收到针对该污染页的再次访问时,宿主机内核态触发缺页异常,将sigbus信号(异常通知信号的一种示例)发送给所有进程或者针对性发送给目标虚拟机。这里的所有进程是宿主机所有的进程,不管是受到这一污染页影响的进程还是不受到这一污染页影响的进程。
在另一些实施例中,发生SRAR和SRAO类型的物理内存异常后,作为一种可实现的方式,通过执行步骤S210~S240,将这两种类型(包含SRAR和SRAO)的异常注入到目标虚拟机中并由目标虚拟机进行相应的异常处理,而不必等到目标虚拟机中的虚拟机进程再次访问被污染的内存页的时候触发更严重的异常(例如触发缺页异常)使得宿主机执行更严苛的异常处理逻辑。
在步骤S320,在上述当前使用状态表示上述异常物理资源未被虚拟机进程使用的情况下,根据物理资源与虚拟机物理资源之间的映射关系,确定上述异常物理资源对应的异常虚拟机物理资源。
发生异常的异常物理资源可以处于以下未被虚拟机进程使用的当前使用状态:(1)被宿主机的一些应用进程(并非是虚拟机(虚拟机整体在宿主机层面相当于一个进程)或者虚拟机内部的进程所使用)使用并发现物理内存异常;或者(2)尚未被宿主机的任何进程使用而是在硬件检查过程中发现物理内存异常。
基于物理资源与虚拟机物理资源之间的映射关系,例如基于物理内存与虚拟机物理内存之间的第一映射关系,可以确定异常物理内存页所对应的目标异常虚拟机物理内存(作为异常虚拟机物理资源的一种示例);基于物理IO(输入输出)与虚拟机IO之间的第二映射关系,可以确定异常IO所对应的目标异常虚拟IO(作为异常虚拟机物理资源的另一种示例)。
在步骤S330,将上述异常虚拟机物理资源的待使用进程确定为上述目标虚拟机进程,将上述目标虚拟机进程所属的虚拟机确定为目标虚拟机。
上述待使用进程不能二次访问发生异常的物理内存对应的异常虚拟机物理资源,避免引发更严重的异常(例如为MCE类异常)。
例如,在异常虚拟机物理资源为异常物理内存页的情况下,则可以将目标异常虚拟机物理内存的待使用进程确定为目标虚拟机进程,例如在电子设备上运行有2个虚拟机,分别为虚拟机1和虚拟机2,虚拟机1上运行有4个应用程序,分别为应用程序A~D,其中目标异常虚拟机物理内存的待使用进程为应用程序A,则可以将应用程序A确定为目标虚拟机进程,应用程序A所在的虚拟机1确定为目标虚拟机。
针对异常IO的情形也可以参照进行理解,这里不再展开说明。
一般而言,对宿主机而言,一个虚拟机就是一个进程,虚拟机内部的多个虚拟机进程不被宿主机关注。相较而言,在包含步骤S310~S330的实施例中,通过确定异常会影响的目标虚拟机进程,定位到虚拟机内受到影响的具体应用进程的层面,并根据目标虚拟机进程所在的目标虚拟机来确定异常所要从宿主机注入的虚拟机对象(即为目标虚拟机),从而提供了一种从更细粒度考虑并从底层(虚拟机内的应用进程)推导到上层(目标虚拟机)的思路。与相关技术中上层定位异常的思路不同,在相关技术中,一般是通过宿主机直接定位到发生问题的虚拟机(虚拟机整体作为宿主机的一个进程),属于从上层(虚拟机这一层面)定位异常的思路。
在步骤S220,根据上述异常的异常信息,生成异常通知信号。
在一些实施例中,上述异常信息包括:发生异常的异常物理资源的对象信息和异常类型。
上述对象信息包括:异常物理资源对应的内存地址和页的大小。
在一些实施例中,参照图5所示,上述异常通知信号为指示UCNA错误类型且为CMCI中断形式的总线通知信号。
具体的总线通知信号可以是SIGBUS信号或者其他通知信号,SIGBUS的通知优先级相对高点,便于被通知的进程能够关注到这一通知。例如参照图4所示,定义的总线通知信号为BUS_CMCIERR_UCNA。
具体可以是在内核的头文件include/uapi/asm-generic/siginfo.h中添加上述用于指示UCNA错误类型且为CMCI中断形式的总线通知信号的宏定义,例如具体代码形式可以为:#define BUS_CMCIERR_UCNA(#表示预处理指令)。
在步骤S230,将上述异常通知信号通过虚拟机管理器注入上述目标虚拟机。
在一些实施例中,参照图4中的step4和图5所示,上述步骤S230中,将上述异常通知信号通过虚拟机管理器注入上述目标虚拟机,包括:将包含上述对象信息和异常类型的异常通知信号发送给虚拟机管理器;由上述虚拟机管理器执行与上述异常通知信号对应的目标异常处理函数。其中,上述目标异常处理函数用于根据上述对象信息进行映射处理,得到虚拟机层面的异常对象信息,并将上述异常对象信息和上述异常类型发送给上述目标虚拟机。
参照图4所示,上述虚拟机管理器为QEMU-KVM架构,QEMU层运行在用户空间,KVM层运行在内核空间。
其中,将包含上述对象信息和异常类型的异常通知信号发送给虚拟机管理器,包括:基于上述对象信息,通过反向映射遍历上述异常物理资源影响的目标进程;在遍历每个目标进程的过程中,确定当前目标进程是否为QEMU-KVM类型的进程;在当前目标进程为QEMU-KVM类型的进程的情况下,将上述总线通知信号发送给当前目标进程对应的目标QEMU-KVM层。
操作系统为每1个物理页面都维护了1个链表,所有与该物理页面关联的页表项都会被放到这个链表上,该链表建立物理页面和所有映射了该物理页面的页表项之间的1种关联,从而让操作系统可以快速定位引用了该物理页面的所有页表项,不再是遍历每个进程的页表。因此,在反向映射机制中,内存管理器(MMU)为每1个物理页建立了1个链表,包含了指向当前映射那个页的每1个进程的页表条目(Page-TableEntries,PTE)的指针。然而基于页表项链表存在为每个物理页面维护这样1个链表,同样需要占用大量的内存空间造成空间资源的消耗,那么在回收1个物理页面的时候,需要先获取该链表上的锁,然后遍历相应的反向映射链表,链表上的项越多,需要的时间越多,造成时间资源消耗越大。为了解决这一弊端,本公开的实施例中采用基于对象的反向映射机制。基于对象的反向映射机制也是为物理页面设置1个用于反向映射的链表,但是链表上的节点不再是引用该物理页面的所有页表项,而是相应的虚拟内存区域(例如为vm_area_struct结构),虚拟内存区域通过内存描述符(例如为mm_struct结构)找到页全局目录,从而找到相应的页表项,在一定程度上也节约了内存空间。用于表示虚拟内存区域的描述符比用于表示页面的描述符要少得多,相应的,遍历基于对象的反向映射链表所消耗的时间也会极大程度减少,从而在一定程度上减少了空间资源和时间资源的消耗。
在一些实施例中,可以先构建特征值为BUS_CMCIERR_UCNA类型的SIGBUS信号;通过反向映射RMAP遍历被污染页映射的所有目标进程,通过判断是否为UCNA类型错误和模式匹配CPU xxx/KVM;如果是vcpu进程(确定当前目标进程是否为QEMU-KVM类型的进程),则将构建的BUS_CMCIERR_UCNA类型的SIGBUS信号通知给该目标进程,总线通知信号中包括发生错误的内存地址和页的大小。
在一些实施例中,上述目标异常处理函数包括:用于向虚拟机内核注入UCNA类型错误的异常注入函数。
其中,由上述虚拟机管理器执行与上述异常通知信号对应的目标异常处理函数,包括:上述目标QEMU-KVM层调用与上述异常通知信号对应的上述异常注入函数;通过上述异常注入函数构建UCNA错误在虚拟机层面对应的目标MCE异常事件结构体;上述目标MCE异常事件结构体包含上述异常对象信息和上述异常类型;上述异常注入函数基于系统调用的方式将上述目标MEC异常事件结构体注入至上述目标虚拟机的操作系统内核。
例如参照图4和图5所示,在QEMU层的代码中增加对特征值为BUS_CMCIERR_UCNA类型的SIGBUS信号的处理函数和增加kvm_inject_ucna(异常注入函数的示例)函数,用于向目标虚拟机注入UCNA错误。当目标QEMU-KVM层接收到BUS_CMCIERR_UCNA类型的SIGBUS信号时,根据处理函数定义的处理策略,调用kvm_inject_ucna这一异常注入函数,基于这一异常注入函数,构建UCNA错误在虚拟机层面对应的目标MCE异常事件结构体struct kvm_x86_mce结构体,并通过ioctl KVM_X86_SET_MCE(系统调用的一种示例性方式)的方式向目标虚拟机guest os注入UCNA类型的内存错误。例如在图4的step5中示意为将UCNA类错误注入到虚拟机的虚拟处理器(guest vcpu)中。
在步骤S240,由上述目标虚拟机进行异常处理。
在一些实施例中,发生异常的异常物理资源(是在宿主机层面进行描述的对象信息)包括以下至少一种:发生UCNA错误类型的异常物理内存页、异常输入输出。
上述异常对象信息是在虚拟机层面对异常对象的描述信息,包括以下至少一种:异常虚拟机物理内存页、异常虚拟输入输出。
在一些实施例中,上述步骤S240中,在上述异常对象信息包括异常虚拟机物理内存页的情况下,由上述目标虚拟机进行异常处理,包括:在上述目标虚拟机中,与上述目标虚拟机进程对应的目标虚拟处理器将已处理结果进行备份,并对上述异常虚拟机物理内存页设置第一已污染标记,上述第一已污染标记用于指示禁止虚拟机进程访问的状态。
例如参照图4中的step6和图5所示,在目标虚拟机内部的虚拟处理器vcpu通过读取目标MCE异常事件结构体中的信息而检测到上述UCNA内存错误后,触发CMCI类型中断,guest内核的CMCI中断服务例程对UCNA错误页进行隔离,隔离的方式可以是通过设置第一已污染标记的方式。虚拟机的虚拟处理器知道相关的虚拟机物理页(实质上是宿主机中发生异常的物理内存页)是被污染页,在隔离被污染页防止二次访问之外,还可以继续做内存错误恢复的处理操作,以保证guest操作系统继续正常运行。
在另一些实施例中,上述步骤S240中,在上述异常对象信息包括异常虚拟输入输出的情况下,由上述目标虚拟机进行异常处理,包括:在上述目标虚拟机中,与上述目标虚拟机进程对应的目标虚拟处理器将已处理结果进行备份,对上述异常虚拟输入输出的端口设置禁用标记,并执行以下至少一种:对上述异常虚拟输入输出对应的文件系统和磁盘进行错误检查和错误修复、对上述目标虚拟机进程进行问题检查和问题修复。
通过在目标虚拟机中针对异常虚拟IO进行异常处理,通过对异常虚拟IO的端口设置禁用标记,有效避免对该异常虚拟IO的二次访问而在宿主机可能触发的更严重的异常风险,同时通过对异常虚拟IO对应的文件系统和磁盘进行错误检查和错误修复,或者对目标虚拟机进程进行问题检查和问题修复,有助于在虚拟机层面检测出可能导致异常虚拟IO的原因和对应进行问题修复。
在包含上述步骤S210~S240的实施例中,在宿主机检测到异常的情况下,通过确定上述异常会影响的目标虚拟机进程(例如目标虚拟机进程为目标虚拟机中的某个应用程序A,目标虚拟机上运行有很多应用程序,诸如A、B、C和D等)及其对应的目标虚拟机,并根据异常的异常信息生成异常通知信号,通过虚拟机管理器将异常通知信号注入到目标虚拟机,由目标虚拟机进行异常处理,提供了一种在检测到异常后生成异常通知信号并通过虚拟机管理器将异常注入至目标虚拟机,由目标虚拟机对应进行异常处理的方案,各种类型的异常在发生后都能够通过虚拟机管理器将异常通知到目标虚拟机,实现了目标虚拟机在受到异常影响的情况下对异常的感知并在虚拟机所在的操作系统层面进行对应处理,避免由于虚拟机对异常不知情而再次触发程度更为严重的异常所导致的必须结束(kill)整个虚拟机(结束虚拟机意味着其上运行的应用程序A~D都被kill)的问题。因此本公开实施例提供的方案能够避免在异常发生后采用一刀切式方式来结束虚拟机引起的虚拟机系统崩溃的缺陷,有效增强虚拟机运行的稳定性。
例如,针对UCNA类异常而言,能够通过异常注入使得目标虚拟机感知到这类异常并通过在目标虚拟机内的异常处理(例如在虚拟机内隔离对应的被污染页,避免二次访问)而有效避免对被污染的内存页的二次访问,从而有效避免引发更严重的异常类型(例如为SRAO和SRAR异常类型),也就有效避免了宿主机结束掉整个虚拟机所导致的问题,从而增强虚拟机运行的稳定性。
本公开的实施例,预先可以在宿主机的BIOS SETUP界面中基于RAS配置项进行内存RAS功能的启用设置,例如可以预先配置UCNA类型内存异常的处理能力。
具体而言,在宿主机的BIOS SETUP界面中基于RAS配置项进行内存RAS功能的启用设置,包括:
设置内存污染(poison)配置项处于启用状态,
设置主动巡检(Acitive Scrub)配置项处于启用状态,
设置主动巡检周期(Active Scrub Interval)配置项的周期参数值,
设置被动巡检(Passive Scrub)配置项处于启用状态,
设置校正错误操作(Correct Error handle)配置项(里面包含Correct ErrorThreshold、Funnel Period和Advance Device Correction)中的可纠正错误阈值(CorrectError Threshold)、设置校正错误操作配置项中的漏斗周期(Funnel Period)为启用状态和设置校正错误操作配置项中的设备错误预先校正功能(Advance Device Correction)为关闭状态。
在一些实施例中,发生异常的物理资源包括以下至少一种:发生UCNA错误类型的异常物理内存页、异常输入输出。
在一些实施例中,上述虚拟机运行稳定性增强的方法还包括宿主机进行异常处理的步骤,参照图4和图5中示意的step1~step3所示。
在step1中,在宿主机检测到发生UCNA错误类型的异常物理内存页的情况下,宿主机对上述异常物理内存页设置第二已污染标记,上述第二已污染标记用于指示禁止宿主机进程访问的状态。
例如宿主机的cpu通过CMCI信号触发Linux内核开机注册的中断服务例程threshold_interrupt执行异常处理步骤。threshold_interrupt这一中断服务例程通过uc_decode notifier通知器调用到memory_failure()这一内存错误处理函数来对错误内存页进行处理,处理过程为具体执行step1~step3。在step1,设置异常物理内存页(在图4中简化描述为错误页)为HWPOISONED(第二已污染标记的示例)。
在step2中,将上述异常物理内存页与对应的虚拟机物理内存页之间的映射关系进行解除。例如,在图4中,将解除异常物理内存页与虚拟机物理内存页之间映射关系的过程描述为try_to_unmap错误页的操作。
具体的,可以通过RMAP反向映射机制去寻找映射该页的所有VMA(虚拟内存空间),并解除相应被污染页的页表(PTE,Page Table Entry)映射。
在step3中,将上述异常物理内存页从物理内存页缓存中删除。例如在图4中示意为从pagecache(物理内存页缓存的示例)的lru(为大小固定的一块内存空间)上删除并setPageError(设置页错误)。
类似的,针对异常IO也可以在宿主机上进行对应的异常处理,例如宿主机对硬件、驱动程序、软件或系统、数据线等进行异常原因检查,并根据检查确认的异常原因而采取对应的处理措施。
例如,异常IO可能是由硬件故障引起的,诸如:硬盘坏道、硬件驱动程序问题、电源故障等。如果遇到异常IO,宿主机可以执行硬件检查操作,例如可以基于硬件检测工具检测硬盘,在发现硬盘存在坏道的情况下,可以基于磁盘修复工具进行修复、或者更换新的硬盘、或者划分新的分区、或者提示更换硬盘等。在检测到电源故障的情况下,可以改用备用电源或者发出更换电源的提示信息。
另外,宿主机还可以执行对硬件驱动程序的检查操作。如果驱动程序存在问题,通过尝试更新或重新安装驱动程序的方式实现IO修复。
另外,异常IO还可能是由于软件或系统问题引起的。有些软件可能会占用硬件资源导致其他程序无法访问硬件设备,从而引发设备I/O错误。宿主机可以执行对软件或系统的检查操作。如果有些软件占用硬件资源导致其他程序无法访问,可以通过关闭其他软件或者强制结束当前占用资源的程序,以实现IO修复。如果是系统导致的异常IO,则可以尝试进行系统还原或者重新安装操作系统。
示例性装置
图6是根据一示例性实施例示出的虚拟机运行稳定性增强的装置的框图。
参照图6所示,本公开实施例提供的虚拟机运行稳定性增强的装置600包括:确定模块610、信号生成模块620、异常注入模块630和异常处理模块640。上述装置600运行有虚拟机。
上述确定模块610用于在宿主机检测到异常的情况下,确定上述异常会影响的目标虚拟机进程及其对应的目标虚拟机。
上述信号生成模块620用于根据上述异常的异常信息,生成异常通知信号。
上述异常注入模块630用于将上述异常通知信号通过虚拟机管理器注入上述目标虚拟机。
上述异常处理模块640设置于上述目标虚拟机内,用于进行异常处理。
在一些实施例中,发生异常的物理资源包括:发生UCNA错误类型的异常物理内存页。上述装置600还包括:宿主机异常处理模块。
上述宿主机异常处理模块设置于宿主机内,用于:在宿主机检测到发生UCNA错误类型的异常物理内存页的情况下,对上述异常物理内存页设置第二已污染标记,上述第二已污染标记用于指示禁止宿主机进程访问的状态;将上述异常物理内存页与对应的虚拟机物理内存页之间的映射关系进行解除;将上述异常物理内存页从物理内存页缓存中删除。
在一些实施例中,上述装置600还包括:配置模块。
上述配置模块用于:在宿主机的BIOS SETUP界面中基于RAS配置项进行内存RAS功能的启用设置。
进行内存RAS功能的启用设置包括:设置内存污染(poison)配置项处于启用状态,设置主动巡检(Acitive Scrub)配置项处于启用状态,设置主动巡检周期(Active ScrubInterval)配置项的周期参数值,设置被动巡检(Passive Scrub)配置项处于启用状态,设置校正错误操作(Correct Error handle)配置项中的可纠正错误阈值(Correct ErrorThreshold)、设置校正错误操作配置项中的漏斗周期(Funnel Period)为启用状态和设置校正错误操作配置项中的设备错误预先校正功能(Advance Device Correction)为关闭状态。
第一个实施例中的具体细节、有益效果以及更多的实施例等内容可以全部并入至本实施例,这里不再赘述。
示例性电子设备
图7是根据一示例性实施例示出的电子设备的框图。
参照图7所示,该电子设备700可以是车辆控制器、车载终端、车载计算机或者其他类型的电子设备,该电子设备700上运行有虚拟机。电子设备700,可包括至少一个处理器710和存储器720。处理器710可以执行存储在存储器720中的指令。处理器710通过数据总线与存储器720通信连接。除存储器720外,处理器710还可通过数据总线与输入设备730、输出设备740、通信设备750通信连接。
处理器710可以是任何常规的处理器,诸如商业可获得的CPU。处理器还可以包括诸如图像处理器(Graphic Process Unit,GPU),现场可编程门阵列(Field ProgrammableGate Array,FPGA)、片上系统(System on Chip,SOC)、专用集成芯片(ApplicationSpecific Integrated Circuit,ASIC)或它们的组合。
存储器720可以由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(SRAM),电可擦除可编程只读存储器(EEPROM),可擦除可编程只读存储器(EPROM),可编程只读存储器(PROM),只读存储器(ROM),磁存储器,快闪存储器,磁盘或光盘。
在本公开实施例中,存储器720中存储有可执行指令,处理器710可以从所述存储器720中读取所述可执行指令,并执行所述指令以实现上述示例性实施例中任一所述的虚拟机运行稳定性增强的方法的全部或部分步骤。
示例性计算机可读存储介质
除了上述方法和装置以外,本公开的示例性实施例还可以是计算机程序产品或存储有该计算机程序产品的计算机可读存储介质。该计算机产品中包括计算机程序指令,该计算机程序指令可被处理器执行,以实现上述示例性实施例中任一方法中描述的全部或部分步骤。
所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本申请实施例操作的程序代码,所述程序设计语言包括面向对象的程序设计语言,诸如Java、C++等,还包括常规的过程式程序设计语言,诸如“C”语言或类似的程序设计语言以及脚本语言(例如Python)。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。
所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。可读存储介质的更具体的例子包括:具有一个或多个导线电连接的静态随机存取存储器(SRAM),电可擦除可编程只读存储器(EEPROM),可擦除可编程只读存储器(EPROM),可编程只读存储器(PROM),只读存储器(ROM),磁存储器,快闪存储器,磁盘或光盘,或者上述的任意合适的组合。
本领域技术人员在考虑说明书及实践本公开后,将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本公开的真正范围和精神由下面的权利要求指出。
应当理解的是,本公开并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (11)

1.一种虚拟机运行稳定性增强的方法,其特征在于,包括:
在宿主机检测到异常的情况下,确定所述异常会影响的目标虚拟机进程及其对应的目标虚拟机;
根据所述异常的异常信息,生成异常通知信号;
将所述异常通知信号通过虚拟机管理器注入所述目标虚拟机;
由所述目标虚拟机进行异常处理。
2.根据权利要求1所述的方法,其特征在于,在宿主机检测到异常的情况下,确定所述异常会影响的目标虚拟机进程及其对应的目标虚拟机,包括:
确定发生异常的异常物理资源的当前使用状态;
在所述当前使用状态表示所述异常物理资源未被虚拟机进程使用的情况下,根据物理资源与虚拟机物理资源之间的映射关系,确定所述异常物理资源对应的异常虚拟机物理资源;将所述异常虚拟机物理资源的待使用进程确定为所述目标虚拟机进程,将所述目标虚拟机进程所属的虚拟机确定为目标虚拟机。
3.根据权利要求1所述的方法,其特征在于,所述异常信息包括:发生异常的异常物理资源的对象信息和异常类型;
将所述异常通知信号通过虚拟机管理器注入所述目标虚拟机,包括:
将包含所述对象信息和异常类型的异常通知信号发送给虚拟机管理器;
由所述虚拟机管理器执行与所述异常通知信号对应的目标异常处理函数;
其中,所述目标异常处理函数用于根据所述对象信息进行映射处理,得到虚拟机层面的异常对象信息,并将所述异常对象信息和所述异常类型发送给所述目标虚拟机。
4.根据权利要求3所述的方法,其特征在于,发生异常的异常物理资源包括以下至少一种:发生UCNA错误类型的异常物理内存页、异常输入输出;所述异常对象信息包括以下至少一种:异常虚拟机物理内存页、异常虚拟输入输出;
在所述异常对象信息包括异常虚拟机物理内存页的情况下,由所述目标虚拟机进行异常处理,包括:
在所述目标虚拟机中,与所述目标虚拟机进程对应的目标虚拟处理器将已处理结果进行备份,并对所述异常虚拟机物理内存页设置第一已污染标记,所述第一已污染标记用于指示禁止虚拟机进程访问的状态;
在所述异常对象信息包括异常虚拟输入输出的情况下,由所述目标虚拟机进行异常处理,包括:
在所述目标虚拟机中,与所述目标虚拟机进程对应的目标虚拟处理器将已处理结果进行备份,对所述异常虚拟输入输出的端口设置禁用标记,并执行以下至少一种:对所述异常虚拟输入输出对应的文件系统和磁盘进行错误检查和错误修复、对所述目标虚拟机进程进行问题检查和问题修复。
5.根据权利要求3所述的方法,其特征在于,所述异常通知信号为指示UCNA错误类型且为CMCI中断形式的总线通知信号;所述虚拟机管理器为QEMU-KVM架构,QEMU层运行在用户空间,KVM层运行在内核空间;
其中,将包含所述对象信息和异常类型的异常通知信号发送给虚拟机管理器,包括:
基于所述对象信息,通过反向映射遍历所述异常物理资源影响的目标进程;
在遍历每个目标进程的过程中,确定当前目标进程是否为QEMU-KVM类型的进程;
在当前目标进程为QEMU-KVM类型的进程的情况下,将所述总线通知信号发送给当前目标进程对应的目标QEMU-KVM层。
6.根据权利要求5所述的方法,其特征在于,所述目标异常处理函数包括:用于向虚拟机内核注入UCNA类型错误的异常注入函数;
其中,由所述虚拟机管理器执行与所述异常通知信号对应的目标异常处理函数,包括:
所述目标QEMU-KVM层调用与所述异常通知信号对应的所述异常注入函数;
通过所述异常注入函数构建UCNA错误在虚拟机层面对应的目标MCE异常事件结构体;所述目标MCE异常事件结构体包含所述异常对象信息和所述异常类型;
所述异常注入函数基于系统调用的方式将所述目标MEC异常事件结构体注入至所述目标虚拟机的操作系统内核。
7.根据权利要求1所述的方法,其特征在于,发生异常的物理资源包括:发生UCNA错误类型的异常物理内存页;
所述方法还包括:
在宿主机检测到发生UCNA错误类型的异常物理内存页的情况下,宿主机对所述异常物理内存页设置第二已污染标记,所述第二已污染标记用于指示禁止宿主机进程访问的状态;
将所述异常物理内存页与对应的虚拟机物理内存页之间的映射关系进行解除;
将所述异常物理内存页从物理内存页缓存中删除。
8.根据权利要求7所述的方法,其特征在于,还包括:
在宿主机的BIOS SETUP界面中基于RAS配置项进行内存RAS功能的启用设置,包括:
设置内存污染配置项处于启用状态,
设置主动巡检配置项处于启用状态,
设置主动巡检周期配置项的周期参数值,
设置被动巡检配置项处于启用状态,
设置校正错误操作配置项中的可纠正错误阈值、设置校正错误操作配置项中的漏斗周期为启用状态和设置校正错误操作配置项中的设备错误预先校正功能为关闭状态。
9.一种虚拟机运行稳定性增强的装置,其特征在于,包括:
确定模块,用于在宿主机检测到异常的情况下,确定所述异常会影响的目标虚拟机进程及其对应的目标虚拟机;
信号生成模块,用于根据所述异常的异常信息,生成异常通知信号;
异常注入模块,用于将所述异常通知信号通过虚拟机管理器注入所述目标虚拟机;
异常处理模块,设置所述目标虚拟机内,用于进行异常处理。
10.一种电子设备,其特征在于,包括:
处理器;
用于存储所述处理器可执行指令的存储器;
所述处理器,用于从所述存储器中读取所述可执行指令,并执行所述指令以实现所述权利要求1-8中任一所述的方法。
11.一种计算机可读存储介质,其上存储有计算机程序指令,其特征在于,该程序指令被处理器执行时,以实现所述权利要求1-8中任一所述的方法。
CN202311121970.2A 2023-08-31 2023-08-31 虚拟机运行稳定性增强的方法、装置、电子设备及介质 Pending CN117170806A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311121970.2A CN117170806A (zh) 2023-08-31 2023-08-31 虚拟机运行稳定性增强的方法、装置、电子设备及介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311121970.2A CN117170806A (zh) 2023-08-31 2023-08-31 虚拟机运行稳定性增强的方法、装置、电子设备及介质

Publications (1)

Publication Number Publication Date
CN117170806A true CN117170806A (zh) 2023-12-05

Family

ID=88940543

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311121970.2A Pending CN117170806A (zh) 2023-08-31 2023-08-31 虚拟机运行稳定性增强的方法、装置、电子设备及介质

Country Status (1)

Country Link
CN (1) CN117170806A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117911196A (zh) * 2024-03-19 2024-04-19 百脉英华科技有限公司 基于人工智能的环网柜全周期运行数据监管系统及方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117911196A (zh) * 2024-03-19 2024-04-19 百脉英华科技有限公司 基于人工智能的环网柜全周期运行数据监管系统及方法
CN117911196B (zh) * 2024-03-19 2024-05-28 百脉英华科技有限公司 基于人工智能的环网柜全周期运行数据监管系统及方法

Similar Documents

Publication Publication Date Title
KR101473119B1 (ko) 메모리의 세그먼트들을 보호하기 위한 방법 및 장치
US6622260B1 (en) System abstraction layer, processor abstraction layer, and operating system error handling
US9804917B2 (en) Notification of address range including non-correctable error
US8099636B2 (en) System and method for protecting memory stacks using a debug unit
US8751736B2 (en) Instructions to set and read memory version information
US20130013843A1 (en) Efficient storage of memory version data
US20110271152A1 (en) Failure management method and computer
WO2007002940A2 (en) Debugging using virtual watchpoints
CN117170806A (zh) 虚拟机运行稳定性增强的方法、装置、电子设备及介质
KR20160106496A (ko) 메모리 관리
US20120233499A1 (en) Device for Improving the Fault Tolerance of a Processor
US20050204199A1 (en) Automatic crash recovery in computer operating systems
US7953914B2 (en) Clearing interrupts raised while performing operating system critical tasks
CN113568777A (zh) 一种故障处理方法、装置、网络芯片、设备及存储介质
CN107818034B (zh) 监测计算机设备中的进程的运行空间的方法以及装置
US8195981B2 (en) Memory metadata used to handle memory errors without process termination
CN115576734A (zh) 一种多核异构日志存储方法和系统
US20220374525A1 (en) Apparatus and method for detecting vulnerability to nonvolatile memory attack
Zhang et al. Software-Based Detecting and Recovering from ECC-Memory Faults
CN116483612B (zh) 内存故障处理方法、装置、计算机设备和存储介质
Sugimoto et al. Short-liveness of error propagation in kernel can improve operating systems availability
CN117472622A (zh) 隔离故障内存的方法、装置、设备及存储介质
KR20160106497A (ko) 메모리 관리
CN117687833A (zh) 测试数据安全的方法、装置及存储介质
CN117472623A (zh) 处理内存故障的方法、装置、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination