发明内容
本发明实施例提供一种为共享代码段打补丁的方法及装置,用以解决现有为共享代码段打补丁的方法中,补丁生效时间较长,影响业务VCPU正常处理业务的缺陷,实现了在不影响业务VCPU正常业务处理的情况下,对共享代码段进行补丁操作并使补丁快速生效。
本发明实施例提供一种为共享代码段打补丁的方法,包括:
为原函数打补丁前,在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令,所述原函数为需要打补丁的共享函数;
向业务VCPU发送第一中断消息,所述第一中断信息用于指示所述业务VCPU中断当前业务,刷新自身的快速指令缓冲区;
在所述共享内存中,将所述原函数的第一条指令和第二条指令修改为跳转到补丁函数的指令,以使执行到所述原函数的所述业务VCPU从所述原函数跳转到所述补丁函数,所述补丁函数为替换所述原函数的函数;
向所述业务VCPU发送第二中断信息,所述第二中断信息用于指示所述业务VCPU中断当前业务,刷新自身的快速指令缓冲区。
本发明实施例提供一种为共享代码段打补丁的方法,包括:
接收到主VCPU发送的第一中断信息后,根据所述第一中断信息的指示,中断当前业务,刷新快速指令缓冲区,以使所述业务VCPU自身的快速指令缓冲区中指令与所述共享内存中指令同步更新,所述原函数为需要打补丁的函数;
执行到原函数的第一条指令时,根据所述原函数的第一条指令,进入异常处理,在所述异常处理中,根据所述原函数的首地址,在补丁区查找出补丁函数的首地址,所述补丁函数为替换所述原函数的函数;根据所述补丁函数的首地址,从所述异常处理跳转到所述补丁函数中执行;
在根据所述第一中断信息的指示,中断当前业务,刷新快速指令缓冲区之后,接收所述主VCPU发送的第二中断信息;
根据所述第二中断信息的指示,中断当前业务,刷新自身的快速指令缓冲区,以使所述业务VCPU自身的快速指令缓冲区中指令与所述共享内存中指令同步更新。
本发明实施例提供一种为共享代码段打补丁的装置,包括:
第一修改模块,用于为原函数打补丁前,在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令,所述原函数为需要打补丁的共享函数;
第一中断模块,用于在所述第一修改模块在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令后,向业务VCPU发送第一中断消息,所述中断信息用于指示所述业务VCPU中断当前业务,刷新自身的快速指令缓冲区;
第一补丁模块,用于在所述第一中断模块向所述业务VPCU发送第一中断信息后,在所述共享内存中,将所述原函数的第一条指令和第二条指令修改为跳转到补丁函数的指令,以使执行到所述原函数的所述业务VCPU从所述原函数跳转到所述补丁函数,所述补丁函数为替换所述原函数的函数;
第二中断模块,用于在所述第一补丁模块在所述共享内存中,将所述原函数的第一条指令和第二条指令修改为跳转到补丁函数的指令后,向所述业务VPCU发送第二中断信息。
本发明实施例提供一种为共享代码段打补丁的装置,包括:
第一刷新模块,用于接收到主VCPU发送的第一中断信息后,根据所述第一中断信息的指示,中断当前业务,刷新快速指令缓冲区,以使所述业务VCPU自身的快速指令缓冲区中指令与所述共享内存中指令同步更新,所述原函数为需要打补丁的函数;
第一异常处理模块,用于在所述第一刷新模块刷新快速指令缓冲区后,执行到原函数的第一条指令时,根据所述原函数的第一条指令,进入异常处理,在所述异常处理中,根据所述原函数的首地址,在补丁区查找出补丁函数的首地址,所述补丁函数为替换所述原函数的函数;
第一补丁函数执行模块,用于在所述第一异常处理模块查找出所述补丁函数的首地址后,根据所述补丁函数的首地址,从所述异常处理跳转到所述补丁函数中执行;
第二刷新模块,用于在所述第一刷新模块根据所述第一中断信息的指示,中断当前业务,刷新快速指令缓冲区之后,接收所述主VCPU发送的第二中断信息,根据所述第二中断信息的指示,中断当前业务,刷新自身的快速指令缓冲区,以使所述业务VCPU自身的快速指令缓冲区中指令与所述共享内存中指令同步更新
本发明实施例为共享代码段打补丁的方法及装置,在多核处理器系统运行过程中,在主VCPU对原函数进行打补丁操作之前,将原函数的第一条指令先修改为跳转到异常处理的指令,并向业务VCPU发送中断信息,使业务VCPU立即刷新快速指令缓冲区。由于,本发明实施例中业务VCPU接收到主CPU发送的中断信息后,不需要向主VCPU发送响应消息;并且主CPU向业务VCPU发送中断信息后,即可对原函数进行打补丁操作,因此,本发明实施例能使补丁快速生效。另外,在主VCPU对原函数打补丁操作时,若业务VCPU执行到原函数则从异常处理进入补丁函数,能保证主VCPU对原函数进行正常的打补丁操作。因此本发明实施例为共享代码段打补丁的方法,在主VCPU对原函数打补丁操作时,不会影响到该业务VCPU的正常业务处理,还能使执行到原函数的业务VCPU从原函数跳转到补丁函数中执行。
本发明实施例提供一种为共享代码段打补丁的方法,包括:
为原函数打补丁前,在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令,所述原函数为需要打补丁的函数;
向各业务VCPU发送第一补丁激活消息,所述第一补丁激活消息用于指示所述业务VCPU在处理完当前业务后刷新自身的快速指令缓冲区,以使所述业务VCPU自身的快速指令缓冲区中指令与所述共享内存中指令同步更新;指示最后一个刷新自身的快速指令缓冲区的VCPU,在刷新自身的快速指令缓冲区之前,在所述共享内存中修改所述原函数的第一条指令和第二条指令。
本发明实施例提供一种为共享代码段打补丁的方法,包括:
业务VCPU接收主VCPU发送的第一补丁激活消息;
当所述业务VCPU是最后一个刷新自身的快速指令缓冲区的业务VCPU时,根据所述第一补丁激活消息的指示,在共享内存中将原函数的第一条指令和第二条指令修改为所述跳转到补丁函数的指令,所述原函数为需要打补丁的函数;
所述业务VCPU刷新自身的快速指令缓冲区,并通过所述主VCPU通知除最后一个刷新自身的快速指令缓冲区的业务VCPU以外的其它业务VCPU刷新自身的快速指令缓冲区,以使所述业务VCPU自身的快速指令缓冲区中指令与所述共享内存中指令同步更新。
本发明实施例提供一种为共享代码段打补丁的装置,包括:
第三修改模块,用于为原函数打补丁前,在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令,所述原函数为需要打补丁的函数;
第一消息发送模块,用于所述第三修改模块在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令后,向各业务VCPU发送第一补丁激活消息,所述第一补丁激活消息用于指示所述业务VCPU在处理完当前业务后刷新自身的快速指令缓冲区,以使所述业务VCPU自身的快速指令缓冲区中指令与所述共享内存中指令同步更新;指示最后一个刷新自身的快速指令缓冲区的VCPU,在刷新自身的快速指令缓冲区之前,在共享内存中修改所述原函数的第一条指令和第二条指令。
本发明实施例提供一种为共享代码段打补丁的装置,包括:
第一接收模块,用于业务VCPU接收主VCPU发送的第一补丁激活消息;
判断模块,用于判断所述业务VCPU是否是最后一个刷新自身的快速指令缓冲区的业务VCPU;
第二补丁模块,用于在所述判断模块判断出所述业务VCPU是最后一个刷新自身的快速指令缓冲区的业务VCPU时,根据所述第一补丁激活消息的指示,在共享内存中将原函数的第一条指令和第二条指令修改为所述跳转到补丁函数的指令,所述原函数为需要打补丁的函数;
第一刷新通知模块,用于在所述第二补丁模块在共享内存中将原函数的第一条指令和第二条指令修改为所述跳转到补丁函数的指令后,刷新所述业务VCPU的快速指令缓冲区,并通过所述主VCPU通知除最后一个刷新自身的快速指令缓冲区的业务VCPU以外的其它业务VCPU刷新自身的快速指令缓冲区,以使所述业务VCPU自身的快速指令缓冲区中指令与所述共享内存中指令同步更新。
本发明实施例为共享代码段打补丁的方法及装置,在多核处理器系统运行过程中,主VCPU将原函数的第一条指令修改为跳转到异常处理的指令后,向业务VCPU发送补丁激活消息,使业务VCPU处理完当前业务后刷新快速指令缓冲区。最后一个刷新快速指令缓冲区的业务VCPU对原函数进行打补丁的操作后,通知其它业务VCPU刷新各自的快速指令缓冲区。在最后一个业务VCPU对原函数进行打补丁操作时,其它业务VCPU若执行到原函数,则从原函数的第一条指令则进入异常处理,再从异常处理中跳转到补丁函数的首地址执行补丁函数中的指令。从而,最后一个业务VCPU对原函数进行补丁操作时,不影响其它业务VCPU的正常业务处理,不会造成业务阻塞和丢失。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
运行于嵌入式操作系统的VCPU称为主VPCU,用于管理系统的公共资源,并对业务VCPU进行管理监控。业务VCPU运行单任务的操作系统,完成高效的用户数据处理。本技术方案适用于非对称处理器AMP(asymmetric multi-processing)结构,每一个VCPU上必须运行单独的操作系统。在VCPU上运行的映像可以独享代码段,也可以共享代码段。
以MIPS(Microcumputer without interlocked pipeline stages)处理器为例,说明在多核处理器环境下的补丁原理。由于MIPS使用了流水线技术,执行指令跳转时存在延迟槽,也就是说实际执行时会先执行延迟槽,再执行跳转指令。所以必须同时修改两条指令,即使用空指令NOP作为延迟槽指令以及修改跳转指令,才能实现打补丁操作。
由于需要修改两条指令才能进行补丁操作,所以在多核处理器的共享代码段情况下,不仅需要考虑指令的修改,而且还需要考虑修改指令的时机以及补丁立即生效问题。因为,在多核处理器中有多个VCPU共同访问相同的代码段,如果某VCPU已经执行到了第一条指令,而另外一个VCPU此时正在修改指令,就会造成第一个VCPU指令异常,从而造成系统崩溃。
本发明实施例分别通过将中断与异常处理相结合的方式,以及消息与异常处理相结合的方式,使补丁快速生效,并且不会影响各业务VCPU的正常业务处理。以下实施例中,第一实施例至第四实施例是,通过中断与异常相结合的方式,在多核处理器系统运行中为共享代码段打补丁的方法;其中,第一实施例与第二实施例从主VCPU角度说明打补丁操作的过程,第三实施例与第四实施例从各业务VCPU角度说明打补丁操作的过程。另外,第五实施例至第八实施例是,通过消息与异常相结合的方式,在多核处理器系统运行中为共享代码段打补丁的方法;其中,第五实施例与第六实施例从主VCPU角度说明打补丁操作的过程,第七实施例与第八实施例从各业务VCPU角度说明打补丁操作的过程。
需要说明的是:以下实施例中的原函数,即为需要打补丁的函数,补丁函数即为替换原函数的函数。
图1a为本发明第一实施例提供的为共享代码段打补丁的方法流程图,本实施例从主VCPU角度说明打补丁操作的过程,如图1所示,本实施例包括:
步骤11:为原函数打补丁前,在共享内存中将原函数的第一条指令修改为跳转到异常处理的指令;
在多核处理器系统运行过程中,主VCPU将原函数的第一条指令修改为跳转到异常处理的指令,其目的是在后续修改原函数过程中,若各业务VCPU执行到原函数,各业务VCPU根据跳转到异常处理的指令进入异常处理。其中,跳转到异常处理的指令可为break.;原函数为需要打补丁的共享函数。
步骤12:向各业务VCPU发送第一中断消息;
中断消息的特点是,各业务VCPU接收到主VCPU以送的中断消息后,立即停止当前下在执行的业务,处理中断消息。主VCPU向各业务VCPU发送第一中断信息,其目的是指示各业务VCPU在接收到第一中断信息后,中断当前业务立即刷新自身的快速指令缓冲区。从而使各业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。由于快速指令缓冲区的存取速度高于内存的存取速度,因此,业务VCPU在执行代码段时,通常会将经常使用的代码段从共享内存中调入自身的快速指令缓冲区中,当使用到这些代码段时,直接从快速指令缓冲中读取,从而提高存取代码速度。
若某个业务VCPU接收到第一中断信息后,已将原函数的第一条指令从共享内存中调到自身的快速指令缓冲区,刷新自身的快速指令缓冲区后,其快速指令缓冲区中该原函数的第一条指令则更新为共享内存中该原函数的第一条指令,即跳转到异常处理的指令。
若某个业务VCPU接收到第一中断信息后,还没将原函数的第一条指令从共享内存中调到自身的快速指令缓冲区,刷新自身的快速指令缓冲区后,其快速指令缓冲区中指令仍为原有指令。
步骤13:在共享内存中,将原函数的第一条指令和第二条指令修改为跳转到补丁函数的指令;
修改原函数的第一条指令和第二条指令,即为原函数打补丁操作。主VCPU在共享内存修改原函数的第一条指令和第二条指令后,使执行到原函数的各业务VCPU,从原函数的第一条指令跳转到补丁函数中,从而实现了对原函数的修改。其中,补丁函数为替换原函数的函数。
修改原函数的方法具体可为:先将原函数的第二条指令修改为延迟槽指令,即NOP;再将原函数的第一条指令修改为跳转到补丁函数的指令,即JMP补丁函数首地址。
若主VCPU先修改原函数的第一条指令,后修改原函数的第二条指令。在主VCPU将原函数的第一条指令从进入异常处理指令修改为跳转指令后,还没未将原函数第二条指令修改为延迟槽指令的情况下,此时执行到原函数第一条指令的业务VCPU,会因为第二条指令不是延迟槽指令,无法跳转到补丁函数中执行,则会导致系统崩溃。
因此,本实施例中先将主VCPU修改先将原函数的第二条指令为延迟槽指令,后修改原函数的第一条指令为跳转指令。此时若业务VCPU执行到原函数到第一条指令,由于此时原函数的第一条指令还是进入异常处理指令(例如,break),业务VCPU则通过第一条指令进入异常处理,而不会再继续执行原函数的第二条指令。从而,本实施例避免了延迟槽指令对共享原函数打补丁的影响。
图1b为本发明第一实施例提供的为共享代码段打补丁的方法中补丁执行流程图。如图1b所示,为原函数打完补丁后,在多核处理器系统运行过程中,业务VCPU执行到调用函数中跳转到原函数的指令时,由调用函数跳转到原函数的第一条指令开始执行。此时,由于原函数的第一条指令为跳转到补丁函数的指令,第二条指令为延迟槽指令,则业务VCPU从原函数跳转到补丁函数中执行。执行到补丁函数的末尾时再返回到调用函数A中,继续执行调用函数A中的指令,从而达到了为原函数打补丁的目的。
步骤14:向各业务VCPU发送第二中断信息;
第二中断信息用于指示业务VCPU,中断当前业务立即刷新各自的快速指令缓冲区,各业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。
在主VCPU在共享内存修改原函数的第一条指令和第二条指令时,某个业务VCPU已将原函数的第一条指令和第二条指令,从共享内存中调入自身的快速指令缓冲区,其刷新自身的快速指令缓冲区后,则会将自身的快速缓冲区中该原函数的第一条指令和第二条指令,更新为主VCPU修改后的原函数的第一条指令和第二条指令。
本实施例,在多核处理器系统运行过程中,在主VCPU对原函数进行打补丁操作之前,将原函数的第一条指令先修改为跳转到异常处理的指令,并向业务VCPU发送中断信息,使业务VCPU立即刷新快速指令缓冲区。由于,本发明实施例中业务VCPU接收到主CPU发送的中断信息后,不需要向主VCPU发送响应消息;并且主CPU向业务VCPU发送中断信息后,即可对原函数进行打补丁操作,因此,本发明实施例能使补丁快速生效。另外,在主VCPU对原函数打补丁操作时,若业务VCPU执行到原函数的第一条指令时,通过上述跳转到异常处理的指令进入异常处理,再从异常处理进入补丁函数,从而能保证主VCPU对原函数进行正常的打补丁操作,同时避免了延迟指令对为共享原函数打补丁的影响。因此本发明实施例为共享代码段打补丁的方法,在主VCPU对原函数打补丁操作时,不会影响到该业务VCPU的正常业务处理,还能使执行到原函数的业务VCPU从原函数跳转到补丁函数中执行,并且不会导致业务阻塞和业务数据丢失。
图2为本发明第二实施例提供的为共享代码段打补丁的方法的流程图。若在图1对应的实施例中,主VCPU在步骤13中对原函数的第一条指令和第二条指令有误,并已执行过步骤14:向各业务VCPU发送第二中断消息,则主VCPU通过本实施例中方法,将原函数的第一条指令和第二条指令恢复为原函数原有指令。在主VCPU恢复原函数的第一条指令和第二条指令的过程中,与图1对应的实施例方法类似,不会的影响到各业务VCPU的正常业务处理,并且还能使执行到原函数第一条指令的业务VCPU,通过异常处理进入补丁数中执行。具体地,如图2所示,本实施例包括:
步骤21:恢复原函数的第一条指令和第二条指令前,在共享内存中将原函数的第一条指令修改为跳转到异常处理的指令;
其中,跳转到异常处理的指令,可为break。
步骤22:向各业务VCPU发送第三中断消息;
第三中断信息用于指示各业务VCPU,中断当前业务立即刷新自身的快速指令缓冲区,以使各业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新;
步骤23:在共享内存中,将原函数的第一条指令和第二条指令,恢复成对原函数修改前的指令;
在步骤23中,主VCPU将原函数的第一条指令和第二条指令,恢复成为原函数打补丁之前的指令,即对原函数修改前的指令。
步骤24:向各业务VCPU发送第四中断信息;
第四中断信息用于指示业务VCPU,中断当前业务立即刷新各自的快速指令缓冲区,以使各业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。
本实施例在主VCPU恢复原函数的第一条指令和第二条指令之前,将原函数的第一条指令先修改为跳转到异常处理的指令,并向业务VCPU发送中断信息,使业务VCPU立即刷新快速指令缓冲区。在主VCPU恢复原函数的第一条指令和第二条指令时,若业务VCPU执行到原函数则通过跳转到异常处理的指令进入异常处理,再从异常处理跳转到补丁函数的首地址处,开始执行补丁函数中的指令,以保证主VCPU对原函数进行修改时。由于,在主VCPU对原函数打补丁操作时,若业务VCPU执行到原函数则从异常处理进入补丁函数,因此本发明为共享代码段打补丁的方法,在主VCPU对原函数打补丁操作时,不影响业务VCPU的正常业务处理,不会造成业务阻塞和数据丢失。
图3a为本发明第三实施例提供的为共享代码段打补丁的方法的流程图。图3b为本发明第三实施例提供的为共享代码段打补丁的方法的信令交互图。本实施例结合图1所示实施例中主VCPU的动作,主要从业务VCPU角度说明打补丁操作的过程。请参见图3a和图3b,本实施例包括:
步骤31:接收到主VCPU发送的第一中断信息后,根据第一中断信息的指示,中断当前业务立即刷新快速指令缓冲区;
各业务VCPU中断当前业务,立即刷新自身快速指令缓冲区的目的是,使自身的快速指令缓冲区中指令与共享内存中指令同步更新,以保证自身的快速指令缓冲区中指令与共享内存中相应指令保持一致。
步骤32:执行到原函数的第一条指令时,根据原函数的第一条指令,进入异常处理;
若某个业务VCPU接收到第一中断信息时,已将原函数的第一条指令从共享内存中调到自身的快速指令缓冲区,刷新自身的快速指令缓冲区后,其快速指令缓冲区中该原函数的第一条指令则更新为共享内存中该原函数的第一条指令,即跳转到异常处理的指令。在还没有接收到主VCPU发送的第二中断信息时,即在自身的快速指令缓冲区中该原函数的第一条指令还没有更新之前,当该业务VCPU执行到第一条指令时,根据跳转到异常处理的指令,进入到异常处理。
若某个业务VCPU接收到第一中断信息时,还没将原函数的第一条指令从共享内存中调到自身的快速指令缓冲区,刷新自身的快速指令缓冲区后,其快速指令缓冲区中指令仍为原有指令。当后续该业务VCPU将该原函数的第一条指令调入快速缓冲区中,在还没有接收到主VCPU发送的第二中断信息时,若执行到了该原函数的第一条指令,由于此时第一条指令为跳转到异常处理的指令,该业务VCPU则根据跳转到异常处理的指令进入异常处理。
步骤33:在异常处理中,根据需要打补丁的原函数的首地址,在补丁区查找补丁函数的首地址;
补丁区存储有原函数的首地址、补丁函数的首地址、原函数与补丁函数的映射关系,以及原函数的前两条指令等信息。
步骤34:根据补丁函数的首地址,从异常处理跳转到补丁函数中执行。
业务VCPU根据原函数的首地址在补丁区查找到对应补丁函数的首地址。查找到对应补丁函数的首地址后,将异常处理的返回地址修改为补丁函数的首地址,然后从异常处理进入到补丁函数,执行补丁函数中指令。因此,在业务VCPU还没有接收到主VPCU发送的第二中断消息之前,即主VCPU对原函数的补丁操作还没生效之前,若业务VCPU执行了该原函数的第一条指令,则会从异常处理中进入到补丁函数进行执行。从而不仅没有影响到以业务VCPU的正常业务处理,而且还能使该业务VCPU执行补丁函数的中指令。
步骤35:在根据第一中断信息的指示,中断当前业务,刷新快速指令缓冲区之后,接收主VCPU发送的第二中断信息,根据第二中断信息的指示,中断当前业务立即刷新自身的快速指令缓冲区。
业务VCPU刷新自身的快速指令缓冲区,会使业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。
在根据第一中断信息的指示,中断当前业务,刷新快速指令缓冲区之后,业务VCPU接收到主VCPU发送的第二中断信息时,说明主VCPU在共享内存中已对原函数的前两条指令进行了修改,若此时自身的快速指令缓冲区存储有该原函数的第一条指令和第二条指令,则刷新快速指令缓冲区后,该原函数的第一条指令和第二条指令,则更新为主VCPU修改后的指令,即第一条为Jump,第二条为Nop。更新后,在该业务VCPU执行到该原函数的第一条指令时,则从原函数直接跳转到补丁函数中执行,从而实现了对原函数的打补丁操作。
本实施例,在多核处理器系统运行过程中,各业务VCPU接收到主CPU发送的第一中断信息后,立即刷新各自的快速指令缓冲区。在业务VCPU执行到原函数的第一条指令时,且没有接收到主VCPU发送的第二中断信息之前,根据跳转到异常处理的指令跳转到异常处理中,然后从异常处理中进入补丁函数中,开始执行补丁函数。因此本发明实施例为共享代码段打补丁的方法,在主VCPU对原函数打补丁操作时,不会影响到该业务VCPU的正常业务处理,还能使执行到原函数的业务VCPU从原函数跳转到补丁函数中执行。
图4a为本发明第四实施例提供的为共享代码段打补丁的方法的流程图。业务VCPU在图3a对应的实施例中接收到主VCPU发送的第二中断信息,并根据对各自的快速指令缓冲区刷新的后,还有可能会接收到主VCPU发送的第三中断信息。图4b为本发明第四实施例提供的为共享代码段打补丁的方法信令交互图。本实施例结合图1、图2对应实施例中主VCPU的执行流程,主要从业务VCPU角度来说明业务VCPU在接收到主VCPU发送的第三中断信息后的执行流程。如图4a和图4b所示,本实施例包括:
步骤41:接收主VCPU发送的第三中断信息后,根据第三中断信息的指示,中断当前业务立即刷新快速指令缓冲区;
业务VCPU接收到主VCPU发送的第三中断信息,说明主VCPU对原函数已进行了修改。各业务VCPU立即刷新自身的快速指令缓冲区,使自身的快速指令缓冲区中指令与共享内存中指令同步更新。
步骤42:执行到原函数的第一条指令时,根据原函数的第一条指令,进入异常处理;
主VCPU向各业务VCPU发送第三中断信息后,对原函数的第一条指令和第二条指令进行恢复操作,使其恢复为原函数中原有的第一条指令和第二条指令。在此过程中,与图3对应的实施例类似,若此时业务VCPU执行到原函数的第一条指令,则通过跳转到异常处理的指令进入异常处理。因此,不会影响到业务VCPU的正常业务处理。
步骤43:在异常处理中,根据需要打补丁的原函数的首地址,在补丁区查找补丁函数的首地址;补丁函数为替换原函数的函数;
步骤44:根据补丁函数的首地址,从异常处理返回到补丁函数中执行。
步骤45:在根据第三中断信息的指示,中断当前业务,刷新快速指令缓冲区之后,接收主VCPU发送的第四中断信息,根据第二中断信息的指示,中断当前业务立即刷新自身的快速指令缓冲区。
业务VCPU刷新自身的快速指令缓冲区,会使业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。
在根据第三中断信息的指示,中断当前业务立即刷新自身的快速指令缓冲区之后,业务VCPU接收主VCPU发送的第四中断信息。
本实施例在多核处理器系统运行过程中,若主VCPU需要恢复之前对原函数第一条指令和第二条指令的修改,事先将原函数的第一条指令修改为跳转到异常处理的指令,然后向各业务VCPU发第三中断信息,使各VCPU刷新各自的指令缓冲区。主VCPU发送第三中断消息后,开始对原函数的前两条指令进行恢复操作,在此阶段,若业务VCPU执行到原函数的第一条指令,则会通过跳转到异常处理指令进入补丁函数。因此本发明实施例为共享代码段打补丁的方法,在主VCPU对原函数进行恢复操作时,不会影响到该业务VCPU的正常业务处理,还能使执行到原函数的业务VCPU从原函数跳转到补丁函数中执行。
图5为本发明第五实施例提供的为共享代码段打补丁的方法流程图,本实施例从主VCPU角度说明打补丁操作的过程,如图5所示,本实施例包括:
步骤51:为原函数打补丁前,在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令;
在多核处理器系统运行过程中,主VCPU将原函数的第一条指令修改为跳转到异常处理的指令,其目的是在后续最后一个VCPU修改原函数过程中,若其它业务VCPU执行到原函数,该业务VCPU根据跳转到导演处理的指令进入异常处理。其中,跳转到异常处理的指令可为break.;原函数为需要打补丁的共享函数。
步骤52:向各业务VCPU发送第一补丁激活消息;
第一补丁激活消息用于指示各业务VCPU在处理完当前业务后刷新自身的快速指令缓冲区,以使各业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新;并指示最后一个刷新自身的快速指令缓冲区的业务VCPU,在共享内存中修改原函数的第一条指令和第二条指令。
为确定出最后一个刷新自身的快速指令缓冲区的业务VCPU,主VCPU发送第一补丁激活消息前,会在共享内存中保存需要接收第一补丁激活消息的所有业务VCPU编号。每一个业务VCPU在接收到补丁激活消息后且刷新自身的快速指令缓冲区之前,都会在共享内存中记录自己的VCPU编号,并查看共享内存中是否已记录有除自身之外的所有业务VCPU的编号,如果是,则表明自己是最后一个业务VCPU。
由于消息的特点,业务VCPU接收到主VCPU发送第一补丁激活消息后,不立即处理该第一补丁激活消息。而是在处理完当前业务后,再刷新自身的快速指令缓冲区。最后一个业务VCPU,在刷新自身的快速指令缓冲区之前,在共享内存中修改原函数的第一条指令和第二条指令,即对原函数进行补丁操作。如果修改原函数指令的业务VCPU不是最后一个刷新瞬自身的快速指令缓冲区的业务VCPU,当该业务VCPU在共享内存中修改原函数的第一条指令和第二指令时,若后续没有刷新自身快速指令缓冲区的其它业务VCPU此时已执行到原函数的第一条指令或第二条指令,则会引起指令执行错误异常因此,本发明实施例中采用最后一个刷新自身缓冲区的VCPU,修改原函数的第一条指令和第二条指令。
业务VCPU处理完当前业务,对接收到第一补丁激活信息进行处理,即刷新自身的快速指令缓冲区后,自身的快速指令缓冲区中存储有原函数的第一条指令,则该条指令为跳转到异常处理的指令。该业务VCPU执行到原函数中的该指令时,进入异常处理,再从异常处理中进入补丁函数。
本发明实施例为共享代码段打补丁的方法,在多核处理器系统运行过程中,主VCPU将原函数的第一条指令修改为跳转到异常处理的指令后,向业务VCPU发送第一补丁激活消息,使业务VCPU处理完当前业务后刷新快速指令缓冲区。最后一个刷新快速指令缓冲区的业务VCPU对原函数进行打补丁的操作后,通知其它业务VCPU刷新各自的快速指令缓冲区。在最后一个业务VCPU对原函数进行打补丁操作时,其它业务VCPU若执行到原函数,则从原函数的第一条指令则进入异常处理,再从异常处理中跳转到补丁函数的首地址执行补丁函数中的指令。从而,最后一个业务VCPU对原函数进行补丁操作时,不影响其它业务VCPU的正常业务处理,不会造成业务阻塞和丢失。
图6为本发明第六实施例提供的为共享代码段打补丁的方法的流程图。在图5对应的实施例步骤52之后,若最后一个刷新自身快速指令缓冲区的业务VCPU对原函数的修改出现错误,则通过本实施例对原函数的指令进行恢复。具体地,如图6所示,本实施例包括:
步骤61:恢复原函数的第一条指令和第二第指令前,在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令;
跳转到异常处理的指令可为break。
步骤62:向各业务VCPU发送第二补丁激活消息;
第二补丁激活消息用于指示各业务VCPU刷新自身的快速指令缓冲区,以使各业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新;并指示各业务VCPU中最后一个刷新自身的快速指令缓冲区的VCPU,在共享内存中,将原函数的第一条指令和第二条指令恢复为原有指令。
本实施例中的第二补丁激活消息,与图5对应实施列中第一补丁激活消息的区别在于,第二补丁激活消息指示最后一个刷新自身的快速指令缓冲区的业务VCPU,在共享内存中,将原函数的第一条指令和第二条指令恢复为原有指令。
本实施例,在多核处理器系统运行过程中,若对原函数的打补丁操作出现错误,需要对原函数的指令恢复时,主VCPU先将原函数的第一条指令修改为跳转到异常处理的指令,并向业务VCPU发送第二补丁激活消息。业务VCPU处理完当前业务后,根据第二补丁激活消息刷新自身的快速指令缓冲区后,若其它业务VCPU执行到原函数的第一条指令即跳转到异常处理的指令,根据跳转到异常处理的指令进入异常处理,再从异常处理中跳转到补丁函数的首地址执行补丁函数中的指令。从而,最后一个业务VCPU对原函数进行恢复操作时,不影响其它业务VCPU的正常业务处理,不会造成业务阻塞和丢失。
图7a为本发明第七实施例提供的一种为共享代码段打补丁的方法的流程图,本实施例主要从业务VCPU角度说明打补丁操作的过程,如图7a所示,本实施例包括:
步骤71a:业务VCPU接收主VCPU发送的第一补丁激活消息;
主VCPU发送第一补丁激活消息的目的是,使各业务VCPU处理完当前业务后,刷新自身快速指令缓冲区。当业务VCPU中的快速指令缓冲区已存储有原函数的第一条指令,此时刷新可以使共享内存中修改后的原函数的第一条指令调入快速指令缓冲区,从而在业务VCPU(除最后一个刷新自身快速指令缓冲区的业务VCPU之外)执行到原函数的第一条指令时,进入异常处理,再从异常处理进入补丁函数中执行。如此,在最后一个业务VCPU对原函数进行打补丁操作(将第一条指令修改为Jump,第二条指令修改为Nop),不影响其它业务VCPU的正常业务处理,而且还能使执行到原函数的其它业务VCPU从原函数跳转到补丁函数中执行。
步骤72a:当业务VCPU是最后一个刷新自身的快速指令缓冲区的业务VCPU时,根据第一补丁激活消息的指示,在共享内存中将原函数的第一条指令和第二条指令修改为跳转到补丁函数的指令;
在业务VCPU处理完当前业务后,准备刷新自身的快速指令缓冲区之前,判断出自身是最后一个刷新自身的快速指令缓冲区的业务VCPU时。在共享内存中将原函数的第一条指令和第二条指令修改为跳转到补丁函数的指令。
步骤73a:业务VCPU刷新自身的快速指令缓冲区,并通过主VCPU通知除最后一个刷新自身的快速指令缓冲区的业务VCPU以外的其它业务VCPU刷新自身的快速指令缓冲区。
业务VCPU刷新自身的快速指令缓冲区,会使自身的快速指令缓冲区中指令与共享内存中指令同步更新。
本发明实施例为共享代码段打补丁的方法,在多核处理器系统运行过程中,主VCPU将原函数的第一条指令修改为跳转到异常处理的指令后,向业务VCPU发送补丁激活消息,使业务VCPU处理完当前业务后刷新快速指令缓冲区。最后一个刷新快速指令缓冲区的业务VCPU对原函数进行打补丁的操作后,通知其它业务VCPU刷新各自的快速指令缓冲区。在最后一个业务VCPU对原函数进行打补丁操作时,其它业务VCPU若执行到原函数,则从原函数的第一条指令则进入异常处理,再从异常处理中跳转到补丁函数的首地址执行补丁函数中的指令。从而,最后一个业务VCPU对原函数进行补丁操作时,不影响其它业务VCPU的正常业务处理,不会造成业务阻塞和丢失。
图7b为本发明第七实施例提供的另一种为共享代码段打补丁的方法的流程图,图7c为本发明第七实施例提供的另一种为共享代码段打补丁的方法的信令交互图。本实施例结合图5对应实施例中主VCPU的执行流程,主要从业务VCPU角度说明打补丁操作的过程,如图7b和图7c所示,本实施例包括:
步骤71:业务VCPU接收主VCPU发送的第一补丁激活消息;
步骤72:判断是否为最后一个刷新自身快速指令缓冲区的业务VCPU;
为确定出最后一个刷新自身的快速指令缓冲区的业务VCPU,主VCPU发送第一补丁激活消息前,会在共享内存中保存需要接收第一补丁激活消息的所有业务VCPU编号。每一个业务VCPU在接收到补丁激活消息后且刷新自身的快速指令缓冲区之前,都会在共享内存中记录自己的VCPU编号。并根据主VCPU在共享内存中保存的需要接收第一补丁激活消息的所有业务VCPU编号,查看共享内存中是否已记录有除自身之外的所有业务VCPU的编号,如果是,则表明自己是最后一个业务VCPU。
若业务VCPU在处理完当前业务,并在刷新自身快速指令缓冲区之前,判断出自己不是最后一个刷新自身快速指令缓冲区的VCPU,则执行步骤73至步骤76,具体如下:
步骤73:刷新自身快速指令缓冲区;
步骤74:在执行到原函数的第一条指令时,根据原函数的跳转到异常处理的指令,进入异常处理;没有执行原函数的第一条指令,表明正常处理业务。
步骤75:在异常处理中,根据需要打补丁的原函数的首地址,在补丁区查找补丁函数的首地址;
步骤76:根据补丁函数的首地址,从异常处理返回到补丁函数中执行。
若业务VCPU在处理完当前业务,并在刷新自身快速指令缓冲区之前,判断出自己是最后一个刷新自身快速指令缓冲区的VCPU,则执行步骤77至步骤78,具体如下:
步骤77:在共享内存中将原函数的第一条指令和第二条指令修改为跳转到补丁函数的指令;
最后一个刷新自身的快速指令缓冲区的业务VCPU,具体修改原函数第一条指令和第二指令的方法可为:先将原函数的第二条指令修改为延迟槽指令,即NOP;再将原函数的第一条指令修改为跳转到补丁函数的指令,即JMP补丁函数首地址。
步骤78:刷新自身的快速指令缓冲区,通过主VCPU通知其它各业务VCPU刷新自身的快速指令缓冲区。
最后一个刷新自身的快速指令缓冲区的业务VCPU,在修改完原函数的第一条指令和第二条指令,刷新自身的快速指令缓冲区,并通过主VCPU通知其它各业务VCPU刷新自身的快速指令缓冲区,以使各业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。
本发明实施例为共享代码段打补丁的方法,在多核处理器系统运行过程中,主VCPU将原函数的第一条指令修改为跳转到异常处理的指令后,向业务VCPU发送补丁激活消息,使业务VCPU处理完当前业务后刷新快速指令缓冲区。最后一个刷新快速指令缓冲区的业务VCPU对原函数进行打补丁的操作后,通知其它业务VCPU刷新各自的快速指令缓冲区。在最后一个业务VCPU对原函数进行打补丁操作时,其它业务VCPU若执行到原函数,则从原函数的第一条指令则进入异常处理,再从异常处理中跳转到补丁函数的首地址执行补丁函数中的指令。从而,最后一个业务VCPU对原函数进行补丁操作时,不影响其它业务VCPU的正常业务处理,不会造成业务阻塞和丢失。
图8a为本发明第八实施例提供的为共享代码段打补丁的方法的流程图。在图7对应的实施例步骤72之后,若最后一个刷新自身快速指令缓冲区的业务VCPU对原函数的修改出现错误,则通过本实施例对原函数的指令进行恢复。图8b为本发明第八实施例提供的为共享代码段打补丁的方法的信令交互图。具体地,如图8a和图8b所示,本实施例包括:
步骤81:接收主VCPU发送的第二补丁激活消息;
主VCPU在共享内存中将原函数的第一条指令修改为跳转到异常处理的指令后,向各业务VCPU发送第二补丁激活消息的目的是,使各业务VCPU处理完当前业务后刷新自身的快速指令缓冲区中指令,以使自身的快速指令缓冲区中指令与共享内存中指令进行同步更新。
与图7对应实施列相类似,在对原函数进行打补丁操作,即同时修改第一条指令和第二条指令之前,主VCPU先将第一条指令修改为break,然后向业务VCPU发送第二补丁激活消息。第二补丁激活消息与第一补丁激活消息的不同在于,指示最后一个刷新快速指令缓冲区的业务VCPU,将原函数的第一条指令和第二条指令,恢复为对原函数修改前的指令。
步骤82:判断自身是否是最后一个刷新自身的快速指令缓冲区的业务VCPU;
各业务VCPU在处理当前业务后,在刷新自身的快速指令缓冲区之前,需判断自身是否是最后一个刷新自身的快速指令缓冲区的业务VCPU,以根据第一补丁激活消息进行不同的操作。若不是最后一个刷新自身的快速指令缓冲区的业务VCPU,则执行步骤83至步骤86:
步骤83:刷新自身的快速指令缓冲区;
步骤84:根据原函数的第一条指令,进入异常处理;
业务VCPU在执行到原函数的第一条指令时,由于其自身的快速指令缓冲区中指令已经过与共享内存的同步更新,其自身的快速指令缓冲区中原函数的第一条指令为跳转到异常处理的指令。因此,该业务VCPU从原函数的第一条指令进入异常处理,执行异常处理程序。没有执行原函数的第一条指令,表明正常处理业务。
步骤85:在异常处理中,根据需要打补丁的原函数的首地址,在补丁区查找补丁函数的首地址;
步骤86:根据补丁函数的首地址,从异常处理返回到补丁函数中执行;
若是最后一个刷新自身的快速指令缓冲区的业务VCPU,则执行步骤87至步骤88,具体如下:
步骤87:在共享内存中恢复原函数的第一条指令和第二条指令;
最后一个刷新自身的快速指令缓冲区的业务VCPU,具体修改原函数第一条指令和第二指令的方法可为:先将原函数的第二条指令(延迟槽指令,即NOP)恢复成对原函数修改前的第二条指令,再将原函数的第一条指令(跳转到异常处理的指令,即break)恢复成对原函数修改前的第一条指令。
步骤88:刷新自身的快速指令缓冲区,通过主VCPU通知其它各业务VCPU刷新自身的快速指令缓冲区。
最后一个刷新自身的快速指令缓冲区的业务VCPU,在恢复原函数的第一条指令和第二条指令后,刷新自身的快速指令缓冲区,并通过主VCPU通知其它各业务VCPU刷新自身的快速指令缓冲区,以使各业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。
本实施例,在多核处理器系统运行过程中,若对原函数的打补丁操作出现错误,需要对原函数的指令恢复时,主VCPU先将原函数的第一条指令修改为跳转到异常处理的指令,并向业务VCPU发送第二补丁激活消息。业务VCPU处理完当前业务后,根据第二补丁激活消息刷新自身的快速指令缓冲区后,若其它业务VCPU执行到原函数的第一条指令即跳转到异常处理的指令,根据跳转到异常处理的指令进入异常处理,再从异常处理中跳转到补丁函数的首地址执行补丁函数中的指令。从而,最后一个业务VCPU对原函数进行恢复操作时,不影响其它业务VCPU的正常业务处理,不会造成业务阻塞和丢失。
以下是对本发明实施例为共享代码段打补丁的装置的说明。其中,第九实施列和第十一实施例是以中断和异常相结合的方式,对原函数进行打补丁的装置;第十二实施例至第十六实施例是以消息和异常相结合的方式,对原函数进行打补丁的装置。
图9为本发明第九实施例为共享代码段打补丁的装置的结构示意图。如图9所示,本实施例包括:第一修改模块91、第一中断模块92和第一补丁模块93以及第二中断模块94。
第一修改模块91在主VCPU为原函数打补丁前,在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令;其中,原函数为需要打补丁的共享函数。第一中断模块92在第一修改模块91在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令后,向业务VCPU发送第一中断消息。第一中断信息用于指示各业务VCPU中断当前业务立即刷新自身的快速指令缓冲区,使第一修改模块91修改后的指令快速生效。从而,在主VCPU为原函数打补丁时,使各业务VCPU根据原函数的第一条指令跳转到异常处理中。
第一补丁模块93在第一中断模块92向业务VPCU发送第一中断信息后,在共享内存中,将原函数的第一条指令和第二条指令修改为跳转到补丁函数的指令。第一补丁模块93的具体操作可为:先将原函数的第二条指令修改为延迟槽指令;将原函数的第一条指令修改为跳转到补丁函数的指令。由于,第一补丁模块93在共享内存中,将原函数的第一条指令和第二条指令修改为跳转到补丁函数的指令时,各业务VCPU已根据第一中断信息的指示,刷新了自身的快速指令缓冲区。因而,若各业务VCPU执行到原函数时,会跳转到异常处理中,从而不会受到第一补丁模块93为原函数打补丁的影响。
第二中断模块94在第一补丁模块93在共享内存中,将原函数的第一条指令和第二条指令修改为跳转到补丁函数的指令后,向业务VPCU发送第二中断信息。第二中断信息用于指示各业务VCPU中断当前业务,刷新自身的快速指令缓冲区,从而使原函数打的补丁函数快速生效。
本实施例中各模块的工作机理参见图1对应实施例中的描述,在此不再赘述。
本实施例,在多核处理器系统运行过程中,在第一补丁模块93对原函数进行打补丁操作之前,第一修改模块91将原函数的第一条指令先修改为跳转到异常处理的指令,并指示第一中断模块92向业务VCPU发送中断信息,使业务VCPU立即刷新快速指令缓冲区。由于,本发明实施例中业务VCPU接收到第一补丁模块93发送的中断信息后,不需要向主VCPU发送响应消息;并且第一补丁模块93向业务VCPU发送中断信息后,即可对原函数进行打补丁操作,因此,本发明实施例能使补丁快速生效。另外,在第一补丁模块93对原函数打补丁操作时,若业务VCPU执行到原函数的第一条指令时,通过上述跳转到异常处理的指令进入异常处理,再从异常处理进入补丁函数,从而能保证第一补丁模块93对原函数进行正常的打补丁操作。因此本发明实施例为共享代码段打补丁的装置,在第一补丁模块93对原函数打补丁操作时,不会影响到该业务VCPU的正常业务处理,还能使执行到原函数的业务VCPU从原函数跳转到补丁函数中执行,并且不会导致业务阻塞和业务数据丢失。
图10为本发明第十实施例为共享代码段打补丁的装置的结构示意图,如图10所示,在图9对应实施例的基础上,还包括:第二修改模块95、第三中断模块96、第一恢复模块97和第四中断模块98。
若第一补丁模块93对原函数的第一条指令和第二条指令有误,并且在第一补丁模块93修改完后,第二中断模块94已向各业务VCPU发送过第二中断信息,则通过本实施例中第一恢复模块,将原函数的第一条指令和第二条指令恢复为对原函数修改前的指令。具体如下:
第二修改模块95已向各业务VCPU发送过第二中断信息后,并在恢复原函数的第一条指令和第二条指令前,在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令。第三中断模块96在第二修改模块95在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令后,向业务VCPU发送第三中断消息,以指示业务VCPU中断当前业务,刷新自身的快速指令缓冲区。第一恢复模块97在第三中断模块96向业务VCPU发送第三中断消息后,在共享内存中,将原函数的第一条指令和第二条指令,恢复成对原函数修改前的指令。第四中断模块98在第一恢复模块97在共享内存中,将原函数的第一条指令和第二条指令,恢复成对原函数修改前的指令后,向业务VCPU发送第四中断信息,以指示业务VCPU,中断当前业务立即刷新各自的快速指令缓冲区,从而使业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。
本实施例中各模块的工作机理参见图2对应实施例中的描述,在此不再赘述。
本实施例在第一恢复模块97恢复原函数的第一条指令和第二条指令之前,第二修改模块95将原函数的第一条指令先修改为跳转到异常处理的指令,并通过第三中断模块96向业务VCPU发送第三中断信息,使业务VCPU立即刷新快速指令缓冲区。在第一恢复模块97恢复原函数的第一条指令和第二条指令时,若业务VCPU执行到原函数则通过跳转到异常处理的指令进入异常处理,再从异常处理跳转到补丁函数的首地址处,开始执行补丁函数中的指令,以保证第一恢复模块97对原函数进行修改时。由于,在第一恢复模块94对原函数打补丁操作时,若业务VCPU执行到原函数则从异常处理进入补丁函数,因此本实施例,在第一恢复模块97对原函数打补丁操作时,不影响业务VCPU的正常业务处理,不会造成业务阻塞和数据丢失。
图11a为本发明第十一实施例为共享代码段打补丁的装置的结构示意图。如图11a所示,本实施例包括:第一刷新模块111、第一异常处理模块112和第一补丁函数执行模块113以及第二刷新模块114。
第一刷新模块111接收到主VCPU发送的第一中断信息后,根据第一中断信息的指示,中断当前业务立即刷新快速指令缓冲区,以使业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。后续,在业务VCPU执行到原函数的第一条指令时,第一异常处理模块112根据原函数的跳转到异常处理的指令,进入异常处理;在异常处理中,根据需要打补丁的原函数的首地址,在补丁区查找补丁函数的首地址;补丁函数为替换原函数的函数。第一异常处理模块112查找到补丁函数的首地址后,第一补丁函数执行模块113从异常处理返回到补丁函数的首地址,并执行补丁函数。
由于主业务VCPU在向业务VCPU发送第一中断信息后,会进行为原函数打补丁的操作,并在为原函数打补丁之后向各业务VCPU发送第二中断信息。因此,第二刷新模块114在第一刷新模块111根据第一中断信息的指示,中断当前业务,刷新快速指令缓冲区之后,接收主VCPU发送的第二中断信息,根据第二中断信息的指示,中断当前业务,刷新自身的快速指令缓冲区,以使业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。
上述各模块的工作机理参见图3a和图3b对应实施例中的描述,在此不再赘述。
若主VCPU为原函数打补丁之后,需要对原函数的第一条指令和第二条指令进行恢复时,如图11b所示,业务VCPU可通过以下模块:第三刷新模块115、第二异常处理模块116、第二补丁函数执行模块117和第四刷新模块118,处理与主VPUC的交互、并不影响当前业务的正常处理。
第三刷新模块115在第二刷新模块114刷新快速指令缓冲区后,接收主VCPU发送的第三中断信息,根据第三中断信息的指示,中断当前业务,刷新自身的快速指令缓冲区。第二异常处理模块116在第三刷新模块115刷新快速指令缓冲区后,执行到原函数的第一条指令时,根据主VCPU原函数的第一条指令,进入异常处理;在异常处理中,根据需要打补丁的原函数的首地址,在补丁区查找出补丁函数的首地址。第二补丁函数执行模块117在第二异常处理模块116查找出补丁函数的首地址后,根据补丁函数的首地址,从异常处理跳转到补丁函数中执行。
第四刷新模块118在第三刷新模块115根据第三中断信息的指示,中断当前业务,刷新自身的快速指令缓冲区之后,接收主VCPU发送的第四中断信息的指示,根据第四中断信息的指示,中断当前业务,刷新自身的快速指令缓冲区,以使业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。
上述各模块的工作机理参见图4a和图4b对应实施例中的描述,在此不再赘述。
本实施例,在多核处理器系统运行过程中,第一刷新模块111接收到主CPU发送的中断信息后,立即刷新各自的快速指令缓冲区。在业务VCPU执行到原函数的第一条指令时,且没有接收到主VCPU发送的第二中断信息之前,根据跳转到异常处理的指令跳转到异常处理中,然后从异常处理中进入补丁函数中,开始执行补丁函数。因此本实施例,在主VCPU对原函数打补丁操作或恢复操作时,不会影响到该业务VCPU的正常业务处理,还能使执行到原函数的业务VCPU从原函数跳转到补丁函数中执行。
图12为本发明第十二实施例为共享代码段打补丁的装置的结构示意图。如图12所示,本实施例包括:第三修改模块121和第一消息发送模块122。
为原函数打补丁前,第三修改模块121在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令。第一消息发送模块122在第三修改模块121在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令后,向各业务VCPU发送第一补丁激活消息。
第一补丁激活消息用于指示各业务VCPU在处理完当前业务后刷新自身的快速指令缓冲区,以使各业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。第一补丁激活消息还指示最后一个刷新自身的快速指令缓冲区的VCPU,在共享内存中修改原函数的第一条指令和第二条指令。
本实施例中各模块的工作机理参见图5对应实施例中的描述,在此不再赘述。
本实施例,在多核处理器系统运行过程中,第三修改模块121将原函数的第一条指令修改为跳转到异常处理的指令后,第一消息发送模块122向业务VCPU发送第一补丁激活消息,使业务VCPU处理完当前业务后刷新快速指令缓冲区。最后一个刷新快速指令缓冲区的业务VCPU对原函数进行打补丁的操作后,通知其它业务VCPU刷新各自的快速指令缓冲区。在最后一个业务VCPU对原函数进行打补丁操作时,其它业务VCPU若执行到原函数,则从原函数的第一条指令则进入异常处理,再从异常处理中跳转到补丁函数的首地址执行补丁函数中的指令。从而,最后一个业务VCPU对原函数进行补丁操作时,不影响其它业务VCPU的正常业务处理,不会造成业务阻塞和丢失。
图13为本发明第十三实施例为共享代码段打补丁的装置的结构示意图。如图13所示,在图12对应实施例的基础上,本实施例还包括:第二消息发送模块124和第四修改模块123。
若最后一个刷新自身快速指令缓冲区的VCPU,对原函数的第一条指令和第二条指令有误,并且已通知过各业务VCPU发送再次刷新自身的快速指令缓冲区。可通过本实施例第二消息发送模块124,向各业务VCPU发送第二激活补丁消息,指示最后一个刷新自身快速指令缓冲区的VCPU。将原函数的第一条指令和第二条指令修改为原函数原有的指令。
具体地,第四修改模块123,在第一消息发送模块向业务VCPU发送第一补丁激活消息之后,在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令。第二消息发送模块124在第四修改模块123在共享内存中,将原函数的第一条指令修改为跳转到异常处理的指令之后,向各业务VCPU发送第二补丁激活消息;第二补丁激活消息用于指示各业务VCPU刷新自身的快速指令缓冲区,以使各业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。第二补丁激活消息还指示各业务VCPU中最后一个刷新自身的快速指令缓冲区的VCPU,在共享内存中,将原函数的第一条指令和第二条指令恢复为对原函数修改前的指令。
本实施例中各模块的工作机理参见图6对应实施例中的描述,在此不再赘述。
本实施例,在多核处理器系统运行过程中,若对原函数的打补丁操作出现错误,需要对原函数的指令恢复时,第四修改模块124先将原函数的第一条指令修改为跳转到异常处理的指令,第二消息发送模块123再向业务VCPU发送第二补丁激活消息。业务VCPU处理完当前业务后,根据第二补丁激活消息刷新自身的快速指令缓冲区后,若其它业务VCPU执行到原函数的第一条指令即跳转到异常处理的指令,根据跳转到异常处理的指令进入异常处理,再从异常处理中跳转到补丁函数的首地址执行补丁函数中的指令。从而,最后一个业务VCPU对原函数进行恢复操作时,不影响其它业务VCPU的正常业务处理,不会造成业务阻塞和丢失。
图14为本发明第十四实施例为共享代码段打补丁的装置的结构示意图。如图14所示,本实施例包括:第一接收模块141、第二补丁模块142和第一刷新通知模块143以及判断模块144。
第一接收模块141接收到主VCPU发送的第一补丁激活消息后,判断模块144判断。当前业务VCPU是否是最后一个刷新自身的快速指令缓冲区的业务VCPU。判断模块144判断出当前业务VPCU是最后一个刷新自身的快速指令缓冲区的业务VCPU时,第二补丁模块142根据第一补丁激活消息的指示,在共享内存中修改原函数的前两条指令。第一刷新通知模块143在第二补丁模块在共享内存中将原函数的第一条指令和第二条指令修改为跳转到补丁函数的指令后,刷新业务VCPU的快速指令缓冲区,并通过主VCPU通知除最后一个刷新自身的快速指令缓冲区的业务VCPU以外的其它业务VCPU刷新自身的快速指令缓冲区,以使业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。
本实施例中各模块的工作机理参见图7a和图7b对应实施例中的描述,在此不再赘述。
本发明实施例为共享代码段打补丁的装置,在多核处理器系统运行过程中,主VCPU将原函数的第一条指令修改为跳转到异常处理的指令后,向业务VCPU发送补丁激活消息,使业务VCPU处理完当前业务后刷新快速指令缓冲区。最后一个刷新快速指令缓冲区的业务VCPU对原函数进行打补丁的操作后,通知其它业务VCPU刷新各自的快速指令缓冲区。在最后一个业务VCPU对原函数进行打补丁操作时,其它业务VCPU若执行到原函数,则从原函数的第一条指令则进入异常处理,再从异常处理中跳转到补丁函数的首地址执行补丁函数中的指令。从而,第二补丁模块142对原函数进行补丁操作时,不影响其它业务VCPU的正常业务处理,不会造成业务阻塞和丢失。
在上述方案中,若第二补丁模块142对原函数的打补丁操作出现错误,需要对原函数的指令恢复时,为不影响业务VCPU的正常执行,主VCPU先将原函数的第一条指令修改为跳转到异常处理的指令,再向业务VCPU发送第二补丁激活消息。第二补丁激活消息指示最后一个业务VCPU刷新自身的快速指令缓冲区之前,对原函数的前两条指令进行恢复操作。因此,在图14对应实施例的基础上,图15对应实施例还包括:第二接收模块145和第二恢复模块146以及第二刷新通知模块147。图15为本发明第十五实施例为共享代码段打补丁的装置的结构示意图。
当第二补丁模块142在共享内存中将原函数的第一条指令和第二条指令修改为跳转到补丁函数的指令后,第二接收模块145接收到主VCPU发送的第二补丁激活消息时。判断模块144判断出当前业务VCPU是最后一个刷新自身的快速指令缓冲区的业务VCPU时。第二恢复模块146根据第二补丁激活消息的指示,在业务VCPU处理完当前业务后,在共享内存中将原函数的第一条指令和第二条指令,恢复成对原函数修改前的指令。
第二刷新通知模块147在第二恢复模块146将在共享内存中将原函数的第一条指令和第二条指令,恢复成对原函数修改前的指令后,刷新业务VCPU的快速指令缓冲区,并通过主VCPU通知除最后一个刷新自身的快速指令缓冲区的业务VCPU以外的其它业务VCPU刷新自身的快速指令缓冲区,以使业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。
本实施例中各模块的工作机理参见图7a和图7b对应实施例中的描述,在此不再赘述。
本实施例中业务VCPU处理完当前业务,根据第二补丁激活消息刷新自身的快速指令缓冲区后,若有业务VCPU执行到原函数的第一条指令即跳转到异常处理的指令,根据跳转到异常处理的指令进入异常处理,再从异常处理中跳转到补丁函数的首地址执行补丁函数中的指令。从而,第二恢复模块146对原函数进行恢复操作时,不影响其它业务VCPU的正常业务处理,不会造成业务阻塞和丢失。
图16为本发明第十六实施例提供的为共享代码段打补丁的装置。如图16所示,在图14对应实施例的基础上,本实施例还包括:第五刷新模块148、第三异常处理模块149和第三补丁函数执行模块140。
第一接收模块141接收到主VCPU发送的第一补丁激活消息或第二接收模块145接收到主VCPU发送的第二补丁激活消息后,第五刷新模块148在判断模块144判断出当前业务VCPU不是最后一个刷新自身的快速指令缓冲区的业务VCPU时,在当前业务VCPU处理完当前业务后,根据第一补丁激活消息或第二补丁激活消息的指示,刷新业务VCPU的快速指令缓冲区。从而,使各业务VCPU自身的快速指令缓冲区中指令与共享内存中指令同步更新。在上述业务VCPU执行到原函数的第一条指令时,第三异常处理模块149根据原函数的跳转到异常处理的指令,进入异常处理;并在异常处理中,根据原函数的首地址,在补丁区查找补丁函数的首地址。第三异常处理模块149查找出补丁函数的首地址后,第三补丁函数执行模块140根据补丁函数的首地址,从异常处理跳转到补丁函数中执行。
上述各模块的工作机理参见图7a、图7b、图8a和图8b对应实施例中的描述,在此不再赘述。
本发明实施例为共享代码段打补丁的装置,在多核处理器系统运行过程中,主VCPU将原函数的第一条指令修改为跳转到异常处理的指令后,向业务VCPU发送补丁激活消息,使业务VCPU处理完当前业务后刷新快速指令缓冲区。最后一个刷新快速指令缓冲区的业务VCPU对原函数进行打补丁的操作后,通知其它业务VCPU刷新各自的快速指令缓冲区。在最后一个业务VCPU对原函数进行打补丁操作时,其它业务VCPU若执行到原函数,则从原函数的第一条指令则进入异常处理,再从异常处理中跳转到补丁函数的首地址执行补丁函数中的指令。从而,第二补丁模块142对原函数进行补丁操作时,不影响其它业务VCPU的正常业务处理,不会造成业务阻塞和丢失。
本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。