CN105630576A - 一种虚拟化平台中的数据处理方法及装置 - Google Patents

Abstract

本发明实施例公开了一种虚拟化平台中的数据处理方法及装置，用于解决现有技术存在的后端驱动频繁唤醒接收线程以及DomU频繁的退出，从而造成现有网络前后端性能低下的问题。该方法包括：Dom0的后端驱动接收虚拟机监控器的事件通道发来的第一数据包；所述后端驱动将接收到的所述第一数据包处理后存储在网络套接字包缓存队列后，在确定所述Dom0的接收线程所处的模式为轮询模式时，无需唤醒所述接收线程，所述轮询模式用于标识接收线程处于非休眠状态。

Description

一种虚拟化平台中的数据处理方法及装置

技术领域

本发明涉及通信技术领域，尤其涉及一种虚拟化平台中的数据处理方法及装置。

背景技术

虚拟化技术是一种新型的计算模式，它支持在单一硬件平台上同时运行多个隔离的虚拟环境，通过将不同的服务部署在这些虚拟环境中，实现多个服务聚合在单一物理节点。

以开放源代码虚拟化产品XEN为例，其包括一个虚拟机监控器(英文：VirtualMachineMonitor，简称：VMM)、一个特权虚拟机(Domain0，简称：Dom0)和多个客户虚拟机(DomainU，简称：DomU)。

VMM运行在客户虚拟机和硬件之间，Dom0与DomU都运行在VMM层之上。Dom0的特殊之处在于：其具有管理其他DomU的管理工具，以及与VMM通信的接口，从而达到对虚拟环境进行控制的目的。Dom0端还包括接收DomU硬件访问信息的接口，称为后端驱动(netback)，后端驱动能够接收同一物理机上所有的DomU的硬件请求。DomU端还包括向Dom0发送硬件请求的接口，称为前端驱动(netfront)。

在Dom0与DomU之间存在一块固定的共享内存，即输入/输出端口(英文：input/output，简称：I/O)环，用于DomU与Dom0之间传递数据请求和响应。Dom0与DomU相互之间交互数据请求和响应需要通过设置于VMM上的事件通道(eventchannel)，即Dom0与DomU相互之间交互数据请求和响应都会经过Dom0<->VMM<->DomU。

前端驱动会事先申请内存空间，将内存地址携带在数据请求(英文：request，简称：req)中放置到IO环上。发往虚拟机的外部数据包(即发往DomU的数据包)首先会到达由VMM管理的物理网卡(NIC)，VMM会通过eventchannel方式发送一个中断请求到Dom0。Dom0会对此中断进行处理，封装相应的数据包为网络套接字包缓存(英文：SocketBuffer，简称：skb)，并通过netback放置到一个skb队列中(skb_list)。

此后，运行于Dom0的一个独立的内核接收线程(vif-rx-qX)会从此skb队列中获取该数据包，并拷贝数据包中包括的数据到IO环上的数据请求(req)携带的内存地址对应的内存空间中，然后将拷贝数据对应的内存地址携带在数据响应中(英文：response，简称：rsp)放置到IO环上之前数据请求(req)所占用的位置，并通过eventchannel发送通知消息来通知DomU的netfront。netfront会从IO环上取出数据响应(rsp)，获取数据响应对应的内存地址存储的数据包，并完成数据包的处理。然后，netfront会再次申请内存空间，携带内存空间的内存地址在数据请求(req)中并放置到IO环上，以供netback继续放置数据响应(req)。

需要注意的是，在此过程中，如果netfront处理速度较慢，导致IO环上被数据响应填满，导致接收线程无法生成新的数据响应放置到IO环，接收线程就会处于等待状态，即接收线程休眠，或者skb队列中没有数据时，接收线程也会休眠；接收线程休眠时即使skb队列中有数据时也不对数据做任何处理。因此，每次在有新数据包到达物理网卡并由Dom0处理放置到skb队列后，netback均会唤醒接收线程从而使得接收线程对skb队列中的数据进行处理。相应的，当DomU的netfront从IO环上读取并处理数据，并申请内存空间并生成新的数据请求放置到IO环上。由于netfront不确定接收线程是否处于休眠状态，因此netfront先需要通过eventchannel通知到Dom0来唤醒接收线程。而DomU的每次eventchannel操作，均会造成DomU的退出，而虚拟化环境下，DomU频繁的退出正是需要尽量避免的。后端驱动频繁唤醒接收线程以及DomU频繁的退出均是造成现有网络前后端性能较低的一个重要因素。

发明内容

本发明实施例提供一种虚拟化平台中的数据处理方法及装置，用于解决现有技术存在的后端驱动频繁唤醒接收线程以及DomU频繁的退出，从而造成现有网络前后端性能低下的问题。

第一方面，本发明实施例提供了一种虚拟化平台中的数据处理方法，该方法包括：

Dom0的后端驱动接收VMM发来的第一数据包；其中VMM通过VMM与后端驱动之间的事件通道向后端驱动发送第一数据包。

所述后端驱动将接收到的所述第一数据包处理后存储在skb队列后，在确定所述Dom0的接收线程所处的模式为轮询模式时，无需唤醒所述接收线程，所述轮询模式用于标识接收线程处于非休眠状态。

在现有技术中后端驱动不知道接收线程是否休眠，因此所述后端驱动将接收到的所述第一数据包处理后存储在skb队列之后，需要唤醒接收线程，但利用本发明实施例提供的方案，所述后端驱动在确定所述Dom0的接收线程所处的模式为轮询模式时，确定了接收线程目前处于非休眠状态，因此无需唤醒所述接收线程，从而避免了后端驱动频繁唤醒接收线程。

在其中一种可能的设计中，后端驱动确定所述接收线程所处的模式为轮询模式，可以通过如下方式实现：

所述后端驱动在被允许读取所述接收线程所处的模式时，读取所述接收线程所处的模式为轮询模式；或者，

所述后端驱动在被禁止读取所述接收线程所处的模式时，则等待预定时间后，再次尝试读取所述接收线程所处的模式，直到被允许且读取到所述接收线程所处的模式为轮询模式。

其中，所述接收线程所处的模式可以存储在所述后端驱动与所述接收线程之间的共享变量中。所述后端驱动尝试向所述共享内存读取所述接收线程所处的模式时，在被允许时，读取到所述接收线程所处的模式。如果被禁止，则所述后端驱动等待预定时间后，再次尝试向所述共享内存读取所述接收线程所处的模式，直到被允许且读取到所述接收线程所处的模式。

由于所述接收线程可以被多个后端驱动使用。因此在其他后端驱动在对所述接收线程的所处的模式修改时，所述后端驱动被禁止读取所述接收线程所处的模式，因此，能够保证所述后端驱动不会读取到接收线程的错误模式而出现处理错误。

在其中一种可能的设计中，所述后端驱动在确定所述Dom0的接收线程所处的模式为轮询模式之后，还包括：

在确定skb队列中的剩余内存空间不小于第二空间阈值且确定接收线程处于所述轮询模式的时间达到时间阈值时，将所述接收线程所处的模式由所述轮询模式修改为所述非轮询模式，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在用户虚拟机DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。

上述设计中，在确定skb队列中的剩余内存空间不小于第二空间阈值且确定接收线程处于所述轮询模式的时间达到时间阈值，也就是说skb队列中在这段时间内接收线程处理的数据包数量较小，因此可以将所述接收线程所处的模式由所述轮询模式修改为所述非轮询模式，也就是在skb队列为空时允许接收线程休眠，从而能够使得接收线程不会长期处于工作状态而浪费资源。

在其中一种可能的设计中，所述方法还可以包括：所述后端驱动接收VMM的事件通道发送的第二数据包；所述后端驱动将接收到的所述第二数据包处理后存储在skb队列中之后，在确定skb队列中的剩余内存空间小于第一空间阈值且确定所述接收线程所处的模式为非轮询模式时，将所述接收线程所处的模式由非轮询模式修改为轮询模式，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在用户虚拟机DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态；所述后端驱动唤醒所述接收线程。

上述设计中，在确定skb队列中的剩余内存空间小于第二空间阈值且确定接收线程处于所述非轮询模式，也就是说skb队列中在这段时间内接收线程处理的数据包数量较大，将所述接收线程所处的模式由所述非轮询模式修改为所述轮询模式，也就是强制在接收线程为轮询模式时不去休眠，从而使得后端驱动在知道接收线程为轮询模式时，不再需要唤醒接收线程，提高了后端的性能。

在其中一种可能的设计中，所述后端驱动在对所述接收线程所处的模式修改时，对所述接收线程所处的模式设置写锁，所述写锁用于禁止其他后端驱动以及所述接收线程读取所述接收线程所处的模式，并

在对所述接收线程所处的模式修改完成后，解除所述写锁。

由于所述接收线程可以被多个后端驱动使用。因此在其他特权虚拟机的后端驱动对所述接收线程所处的模式进行修改时，可以对所述接收线程所处的模式设置写锁，所述写锁，用于禁止除所述对所述接收线程的模式进行修改的后端驱动以外的其他后端驱动以及所述接收线程读取所述接收线程所处的模式。那么在对所述接收线程所处的模式修改完成后，解除所述写锁。通过设置写锁可以保证在所述接收线程的模式被修改时，其他的后端驱动以及所述接收线程不会读取到错误的模式而出现错误。

第二方面，本发明实施例还提供了一种虚拟化平台中的数据处理方法，该方法包括：

Dom0的接收线程尝试对skb队列中的数据包进行处理时，确定skb队列为空或者确定DomU的前端驱动与所述Dom0的后端驱动之间的共享内存为满时，读取所述接收线程需处于的模式；

所述接收线程在读取到所述模式为轮询模式时，无需休眠；所述轮询模式用于标识接收线程处于非休眠状态。

在现有技术中确定skb队列为空或者确定DomU的前端驱动与所述Dom0的后端驱动之间的共享内存为满，接收线程一定休眠，在本发明实施例提供的方案中，接收线程在确定模式为轮询模式时，不会去休眠，也就是接收线程在轮询模式时，无论是什么情况下均不会休眠。保证后端驱动和前端驱动在轮询模式时不去唤醒接收线程，提高了前后端驱动的接收性能。

在其中一种可能的设计中，所述接收线程在读取到所述模式为轮询模式后，还包括：

所述接收线程确定上一次读取到的所述接收线程需处于的模式为非轮询模式时，所述接收线程向用户虚拟机DomU的前端驱动发送用于通知所述接收线程的模式由非轮询模式更改为轮询模式的通知信息；

所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在用户虚拟机DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。

在现有技术中，前端驱动在生成数据请求并放置在前端驱动与后端驱动之间的共享内存之后，都会尝试唤醒接收线程。而在本发明实施例中，由于接收线程，在确定自身所处的模式发生变化时，已经通知前端驱动所述接收线程是由非轮询模式变为轮询模式，因此，前端驱动可以将所述接收线程的模式存储下来。从而前端驱动生成第一数据请求放置在所述前端驱动与后端驱动之间的共享内存之后，读取自身存储的所述接收线程的模式，在确定读取到所述接收线程的模式为轮询模式时，无需向所述Dom0的接收线程发送唤醒请求，提高了前后端驱动的接收性能。

在其中一种可能的设计中，所述接收线程读取所述接收线程需处于的模式时，可以通过如下方式实现：

所述接收线程在被允许读取所述接收线程需处于的模式时，读取所述接收线程需处于的模式，或者，

所述接收线程在被禁止读取所述接收线程需处于的模式时，则等待预定时间后，再次尝试读取所述接收线程需处于的模式，直到被允许读取所述接收线程需处于的模式。

通过上述方式能够避免接收线程读取错误的模式。

在其中一种可能的设计中，所述接收线程确定skb队列为空或者确定用户虚拟机DomU的前端驱动与所述特权虚拟机Dom0的后端驱动之间的共享内存为满之后，所述方法还可以包括：

所述接收线程读取到所述接收线程需处于非轮询模式且确定上一次读取到所述接收线程需处于的模式为轮询模式时，向所述前端驱动发送用于通知所述接收线程的模式由轮询模式更改为非轮询模式的通知信息。

接收线程在读取到所述接收线程需处于非轮询模式且上一次读取到所述接收线程需处于的模式为轮询模式，也就是说接收线程在满足条件时要休眠，因此将该修改通知给前端驱动，从而使得前端驱动能够在得知接收线程为非轮询模式时唤醒接收线程。

第三方面，本发明实施例提供了一种虚拟化平台中的数据处理方法，该方法包括：

DomU的前端驱动生成第一数据请求放置在所述前端驱动与Dom0的后端驱动之间的共享内存；

前端驱动确定Dom0的接收线程所处的模式为轮询模式时，无需向所述Dom0的接收线程发送唤醒请求，所述轮询模式用于标识接收线程处于非休眠状态。

通过上述方式，前端驱动确定接收线程所处的模式为轮询模式时，无需向所述Dom0的接收线程发送唤醒请求，从而能够避免domU的频繁退出造成的前后端接收性能低下。

在其中一种可能的设计中，所述方法还可以包括：

所述前端驱动生成第二数据请求放置在所述前端驱动与Dom0的后端驱动之间的共享内存；

所述前端驱动接收到所述接收线程发送的用于通知所述接收线程的模式由轮询模式更改为非轮询模式的通知信息时，所述前端驱动向所述接收线程发送用于唤醒所述接收线程的唤醒请求，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。

前端驱动接收到所述接收线程发送的用于通知所述接收线程的模式由轮询模式更改为非轮询模式的通知信息时，确定了所述接收线程的模式由轮询模式更改为非轮询模式，也就是接收线程此刻处于非轮询模式了，因此不能确定此刻所述接收线程是否休眠了，所述前端驱动需要向所述接收线程发送用于唤醒所述接收线程的唤醒请求。

第四方面，本发明实施例还提供了一种虚拟化平台中的数据处理装置，所述数据处理装置应用于Dom0的后端驱动，包括：

接收单元，用于接收VMM的事件通道发来的第一数据包；

处理单元，用于将所述接收单元接收到的所述第一数据包处理后存储在skb队列后，在确定所述Dom0的接收线程所处的模式为轮询模式时，无需唤醒所述接收线程，所述轮询模式用于标识接收线程处于非休眠状态。

在一种可能的设计中，所述处理单元，在确定所述接收线程所处的模式为轮询模式具体用于：

所述后端驱动在被允许读取所述接收线程所处的模式时，读取所述接收线程所处的模式为轮询模式。

在其中一种可能的设计中，所述处理单元，在确定所述接收线程所处的模式为轮询模式时，具体用于：

在被禁止读取所述接收线程所处的模式时，则等待预定时间后，再次尝试读取所述接收线程所处的模式，直到被允许且读取到所述接收线程所处的模式为轮询模式。

在其中一种可能的设计中，所述处理单元在确定所述Dom0的接收线程所处的模式为轮询模式之后，还用于：

在确定skb队列中的剩余内存空间不小于第二空间阈值且确定接收线程处于所述轮询模式的时间达到时间阈值时，将所述接收线程所处的模式由所述轮询模式修改为所述非轮询模式，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。

在其中一种可能的设计中，所述接收单元，还用于接收VMM的事件通道发送的第二数据包；

所述处理单元，还用于将所述接收单元接收到的所述第二数据包处理后存储在skb队列中之后，在确定skb队列中的剩余内存空间小于第一空间阈值且确定所述接收线程所处的模式为非轮询模式时，将所述接收线程所处的模式由非轮询模式修改为轮询模式，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态；唤醒所述接收线程。

在其中一种可能的设计中，所述处理单元，还用于在对所述接收线程所处的模式修改时，对所述接收线程所处的模式设置写锁，所述写锁用于禁止其他后端驱动以及所述接收线程读取所述接收线程所处的模式，并

在对所述接收线程所处的模式修改完成后，解除所述写锁。

第五方面，本发明实施例还提供了一种虚拟化平台中的数据处理装置，所述数据处理装置应用于Dom0的接收线程，包括：

确定单元，用于在尝试对skb队列中的数据包进行处理时，确定skb队列是否为空或者确定DomU的前端驱动与所述Dom0的后端驱动之间的共享内存是否为满；

所述读取单元，在确定skb队列为空或者确定DomU的前端驱动与所述Dom0的后端驱动之间的共享内存为满时，读取所述接收线程需处于的模式；并在读取到所述模式为轮询模式时，所述接收线程无需休眠；所述轮询模式用于标识接收线程处于非休眠状态。

在其中一种可能的设计中，所述确定单元，还用于在所述读取单元读取到所述模式为轮询模式后，确定上一次读取到的所述接收线程需处于的模式；

还包括：

第一通知单元，在确定上一次读取到的所述接收线程需处于的模式为非轮询模式时，向DomU的前端驱动发送用于通知所述接收线程的模式由非轮询模式更改为轮询模式的通知信息；

所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。

在其中一种可能的设计中，所述读取单元，在读取所述接收线程需处于的模式，具体用于在被允许读取所述接收线程需处于的模式时，读取所述接收线程需处于的模式。

在其中一种可能的设计中，所述读取单元，在读取所述接收线程需处于的模式，具体用于：

在被禁止读取所述接收线程需处于的模式时，则等待预定时间后，再次尝试读取所述接收线程需处于的模式，直到被允许读取所述接收线程需处于的模式。

在其中一种可能的设计中，还包括：

第二通知单元，用于在所述确定单元确定skb队列为空或者确定DomU的前端驱动与所述Dom0的后端驱动之间的共享内存为满之后，所述读取单元读取到所述接收线程需处于非轮询模式且所述确定单元确定上一次读取到所述接收线程需处于的模式为轮询模式时，向所述前端驱动发送用于通知所述接收线程的模式由轮询模式更改为非轮询模式的通知信息。

第六方面，本发明实施例还提供了一种虚拟化平台中的数据处理装置，所述数据处理装置应用于DomU的前端驱动，包括：

处理单元，用于生成第一数据请求并放置在所述前端驱动与特权虚拟机Dom0的后端驱动之间的共享内存；

发送单元，用于在所述处理单元确定Dom0的接收线程所处的模式为轮询模式时，无需向所述Dom0的接收线程发送唤醒请求，所述轮询模式用于标识接收线程处于非休眠状态。

在其中一种可能的设计中，所述处理单元，还用于生成第二数据请求放置在所述前端驱动与所述后端驱动之间的共享内存；

还包括：

接收单元，用于接收所述接收线程发送的用于通知所述接收线程的模式由轮询模式更改为非轮询模式的通知信息；

所述发送单元，还用于在所述接收单元接收到所述通知信息时，向所述接收线程发送用于唤醒所述接收线程的唤醒请求，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。

Dom0的后端驱动接收VMM的事件通道发来的第一数据包，现有技术中后端驱动不知道接收线程是否休眠，因此所述后端驱动将接收到的所述第一数据包处理后存储在网络套接字包缓存skb队列之中，需要唤醒接收线程，但利用本发明实施例提供的方案，所述后端驱动在确定所述Dom0的接收线程所处的模式为轮询模式时，确定了接收线程目前处于非休眠状态，因此无需唤醒所述接收线程，所述轮询模式用于标识接收线程处于非休眠状态，从而避免了后端驱动频繁唤醒接收线程。

在DomU的前端驱动生成第一数据请求放置在所述前端驱动与Dom0的后端驱动之间的共享内存后，现有技术中DomU的前端驱动不知道接收线程此刻是否休眠，因此需要唤醒接收线程，利用本发明实施例提供的方案，确定Dom0的接收线程所处的模式为轮询模式时，确定了接收线程此刻处于非休眠状态，因此无需向所述Dom0的接收线程发送唤醒请求，从而避免了DomU频繁的退出。

附图说明

图1为本发明实施例提供的虚拟化平台示意图；

图2为本发明实施例提供的虚拟化平台中的设备实现数据处理流程示意图；

图3为本发明实施例提供的netback进行数据处理的流程图；

图4为本发明实施例提供的接收线程进行数据处理的流程图；

图5为本发明实施例提供的netfront进行数据处理的流程图；

图6为本发明实施例提供的一种应用于后端驱动的数据处理装置示意图；

图7为本发明实施例提供的另一种应用于后端驱动的数据处理装置示意图；

图8为本发明实施例提供的一种应用于接收线程的数据处理装置示意图；

图9为本发明实施例提供的另一种应用于接收线程的数据处理装置示意图；

图10为本发明实施例提供的一种应用于前端驱动的数据处理装置示意图；

图11为本发明实施例提供的另一种应用于前端驱动的数据处理装置示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

本发明实施例提供一种虚拟化平台中的数据处理方法及装置，用于解决现有技术存在的后端驱动频繁唤醒接收线程以及DomU频繁的退出，从而造成XEN下现有网络前后端性能低下的问题。其中，方法和装置是基于同一发明构思的，由于方法及装置解决问题的原理相似，因此装置与方法的实施可以相互参见，重复之处不再赘述。

本发明实施例应用于一种虚拟化平台，如图1所示，该虚拟化平台包括虚拟机监控器(英文：VirtualMachineMonitor，简称：VMM)、一个特权虚拟机(Domain0，简称：Dom0)和多个客户虚拟机(DomainU，简称：DomU)。

VMM运行在客户虚拟机和硬件之间，Dom0与DomU都运行在VMM层之上。VMM用于管理物理网卡(NIC)，发往DomU的数据包首先会到达NIC。

Dom0的特殊之处在于：其具有管理其他DomU的管理工具，以及与VMM通信的接口，从而达到对虚拟环境进行控制的目的。Dom0端还包括接收DomU硬件访问信息的接口，称为后端驱动(netback)，后端驱动能够接收同一物理机上所有的DomU的硬件请求。DomU端还包括向Dom0发送硬件请求的接口，称为前端驱动(netfront)。

在Dom0与DomU之间存在一块固定的共享内存，即输入/输出端口(英文：input/output，简称：I/O)环，用于DomU与Dom0之间传递数据请求和数据响应。Dom0与DomU相互之间交互数据请求和数据响应需要通过设置于VMM上的事件通道(eventchannel)，即Dom0与DomU相互之间交互数据请求和数据响应都会经过Dom0<->VMM<->DomU。

基于图1所示的虚拟化平台，虚拟化平台中的设备实现数据处理的流程如图2所示。

参见图3，为本发明实施例提供的应用于上述虚拟化平台的一种数据处理的方法流程。

DomU的netfront预先申请内存空间。该内存空间用于存储发往该DomU的数据包。针对该内存空间，其中DomU可以访问，另外Dom0也可以访问。

DomU的netfront将申请的内存空间的内存地址携带在数据请求(req)中放置到I/O环上。例如图2中实线I/O环中所示的req1～req6。

VMM确定NIC接收到发往DomU的第一数据包。VMM将所述第一数据包通过事件通道发送给Dom0的netback。

其中，事件通道包括Dom0与VMM之间的以及DomU与VMM之间的。具体的，VMM将所述第一数据包通过Dom0与VMM之间的事件通道发送给Dom0的netback。

下面具体描述netback的处理流程，如图3所示。

S301，Dom0的netback在接收到VMM发送的所述第一数据包后，对所述第一数据包处理后存储在skb队列。本发明实施例中以skb队列为skb_list为例，如图2所示。

具体的，Dom0的netback将所述第一数据包进行封装，具体封装为skb的格式，然后放置到skb_list中。

S302，netback确定所述Dom0的接收线程所处的模式为轮询模式，无需唤醒所述接收线程。

其中接收线程所处的模式包括轮询模式和非轮询模式。轮询模式用于标识接收线程处于非休眠模式。所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在DomU的netfront与所述netback之间共享的I/O环为满时处于休眠状态。

在现有技术中netback不知道接收线程是否休眠，因此所述netback将接收到的所述第一数据包处理后存储在skb队列之后，需要唤醒接收线程，但利用本发明实施例提供的方案，所述netback在确定所述Dom0的接收线程所处的模式为轮询模式时，确定了接收线程目前处于非休眠状态，因此无需唤醒所述接收线程，从而避免了netback频繁唤醒接收线程。

其中，可以设置接收线程一直处于轮询模式。则接收线程所处的模式一直处于轮询模式，不会更改到非轮询模式，这样能够保证接收线程一直不会休眠。但是这样接收线程一直处于工作状态，会造成浪费资源。因此可以设置接收线程所处的模式在满足某个条件下能够变为非轮询模式。

因此，可选的，netback确定所述Dom0的接收线程所处的模式为轮询模式之后，还可以包括：

netback在确定skb队列中的剩余内存空间不小于第二空间阈值且确定接收线程处于所述轮询模式的时间达到时间阈值时，将所述接收线程所处的模式由所述轮询模式修改为所述非轮询模式。

在确定skb队列中的剩余内存空间不小于第二空间阈值且确定接收线程处于所述轮询模式的时间达到时间阈值，也就是说skb队列中在这段时间内接收线程处理的数据包数量较小，因此可以将所述接收线程所处的模式由所述轮询模式修改为所述非轮询模式，也就是在skb队列为空时允许接收线程休眠，从而能够使得接收线程不会长期处于工作状态而浪费资源。

那么由于接收线程处于非轮询模式时，也就是现有技术中接收线程所处的状态，则接收线程在确定skb队列中的剩余内存空间为空或者在DomU的netfront与所述netback之间共享的I/O环为满时，会休眠，因此能够使得接收线程在没有数据需要处理时，或者所处理的数据无法放置到I/O环来使得netfront处理时，进行休眠，从而能够避免接收线程一直处于工作状态，造成的资源浪费。

其中，netback确定所述Dom0的接收线程所处的模式为轮询模式，具体包括：

所述netback在被允许读取所述接收线程所处的模式时，读取所述接收线程所处的模式为轮询模式；或者，

所述netback在被禁止读取所述接收线程所处的模式时，则等待预定时间后，再次尝试读取所述接收线程所处的模式，直到被允许且读取到所述接收线程所处的模式为轮询模式。

由于所述接收线程可以被多个netback使用。因此在其他netback在对所述接收线程的所处的模式修改时，所述netback被禁止读取所述接收线程所处的模式，因此，能够保证所述netback不会读取到接收线程的错误模式而出现处理错误。另外，在其他特权虚拟机的netback对所述接收线程所处的模式进行修改时，可以对所述接收线程所处的模式设置写锁，所述写锁，用于禁止除所述对所述接收线程的模式进行修改的netback以外的其他netback以及所述接收线程读取所述接收线程所处的模式。那么在对所述接收线程所处的模式修改完成后，解除所述写锁，因此所述netback在被禁止读取所述接收线程所处的模式时，则等待预定时间后，可以再次尝试读取所述接收线程所处的模式。

通过设置写锁可以保证在所述接收线程的模式被修改时，其他的netback以及所述接收线程不会读取到错误的模式而出现错误。

其中，netback和接收线程是属于同一个虚拟机操作系统内部的两个线程，接收线程模式可以存储在两个线程都可以读取的共享变量中。因此，netback对所述共享变量中存储的接收线程的模式修改时，在所述共享变量中对所述接收线程的模式设置写锁。

可选地，所述方法还可以包括：所述netback接收VMM的事件通道发送的第二数据包；所述netback将接收到的所述第二数据包处理后存储在skb队列中之后，在确定skb队列中的剩余内存空间小于第一空间阈值且确定所述接收线程所处的模式为非轮询模式时，将所述接收线程所处的模式由非轮询模式修改为轮询模式，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在netfront与所述netback之间的共享内存为满时处于休眠状态；所述netback唤醒所述接收线程。

上述设计中，在确定skb队列中的剩余内存空间小于第二空间阈值且确定接收线程处于所述非轮询模式，也就是说skb队列中在这段时间内接收线程处理的数据包数量较大，将所述接收线程所处的模式由所述非轮询模式修改为所述轮询模式，也就是强制在接收线程为轮询模式时不去休眠，从而使得netback在知道接收线程为轮询模式时，不再需要唤醒接收线程，提高了后端的性能。

在netback进行上述处理后，接收线程会做如下处理，如图4所示。

S401，Dom0的接收线程尝试对skb队列中的数据包进行处理时，确定skb队列为空或者确定DomU的netfront与所述Dom0的netback之间的I/O环为满时，读取所述接收线程需处于的模式。

首先在netback对接收线程的模式进行修改时，可以不设置写锁，也可以设置写锁。在不设置写锁时，接收线程在读取自身需处于的模式时，不需要确定是否被允许读取所述接收线程需处于的模式。若是设置写锁，接收线程在读取所述接收线程需处于的模式时，可以通过以下方式实现：

所述接收线程在被允许读取所述接收线程需处于的模式时，读取所述接收线程需处于的模式；或者，

所述接收线程在被禁止读取所述接收线程需处于的模式时，则等待预定时间后，再次尝试读取所述接收线程需处于的模式，直到被允许读取所述接收线程需处于的模式。

S402，所述接收线程在读取到所述模式为轮询模式时，无需休眠。

所述轮询模式用于标识接收线程处于非休眠状态。

在现有技术中确定skb队列为空或者确定用户虚拟机DomU的netfront与所述特权虚拟机Dom0的netback之间的共享内存为满，接收线程一定休眠，在本发明实施例提供的方案中，接收线程在确定模式为轮询模式时，不会去休眠，也就是接收线程在轮询模式时，无论是什么情况下均不会休眠。保证netback和netfront在轮询模式时不去唤醒接收线程，提高了前netback的接收性能。

若在skb队列为空的条件下，接收线程不进行休眠后，接收线程可以等待，每隔一段时间去尝试对skb队列中的数据包进行处理。

其中，在skb不为空并且确定DomU的netfront与所述Dom0的netback之间的I/O环不为满，则接收线程肯定不会休眠。接收线程对skb队列中的数据包进行处理，读取一个数据包，并拷贝数据包中包括的数据到I/O环上的数据请求(req)携带的内存地址对应的内存空间中，然后将拷贝的数据对应的内存地址携带在数据响应中放置到IO环上之前数据请求(req)所占用的位置，并通过eventchannel发送通知消息来通知DomU的netfront有数据需要处理。从而netfront读取I/O环，对数据响应中携带的内存地址所存储的数据进行处理。

例如，这里以数据响应为rep1为例，则将图2实线I/O环中所示的rsq1替换为虚线I/O环中放置rep1。

具体的，S401中接收线程可以尝试对skb队列中的数据包进行处理。那么首先确定skb队列是否为空或者确定DomU的netfront与所述Dom0的netback之间的I/O环是否为满。

若确定skb队列为空或者确定DomU的netfront与所述Dom0的netback之间的共享I/O环为满时，读取所述接收线程需要处于的模式，所述接收线程在读取到所述模式为轮询模式时，无需休眠。由于所述接收线程尝试对skb队列中的数据包进行处理，此刻所述接收线程肯定处于非休眠状态，因此无需休眠也就是接收线程保持非休眠状态。

可选的，所述接收线程确定上一次读取到的所述接收线程需处于的模式为非轮询模式时，所述接收线程向DomU的netfront发送用于通知所述接收线程的模式由非轮询模式更改为轮询模式的通知信息。

在现有技术中，netfront在生成数据请求并放置在netfront与netback之间的共享内存之后，都会尝试唤醒接收线程。而在本发明实施例中，由于接收线程，在确定自身所处的模式发生变化时，已经通知netfront所述接收线程是由非轮询模式变为轮询模式，因此，netfront可以将所述接收线程的模式存储下来。从而netfront生成第一数据请求放置在所述netfront与netback之间的共享内存之后，读取自身存储的所述接收线程的模式，在确定读取到所述接收线程的模式为轮询模式时，无需向所述Dom0的接收线程发送唤醒请求，提高了前netback的接收性能。

可选的，所述接收线程确定skb队列为空或者确定DomU的netfront与所述Dom0的netback之间的I/O环为满之后，所述接收线程读取到所述接收线程需处于非轮询模式且确定上一次读取到所述接收线程需处于的模式为轮询模式时，向所述netfront发送用于通知所述接收线程的模式由轮询模式更改为非轮询模式的通知信息。

接收线程在读取到所述接收线程需处于非轮询模式且上一次读取到所述接收线程需处于的模式为轮询模式，也就是说接收线程在满足条件时要休眠，因此将该修改通知给netfront，从而使得netfront能够在得知接收线程为非轮询模式时唤醒接收线程。

这里接收线程读取所述接收线程需处于的模式，可以从接收线程与netback之间的共享变量中读取。

其中，netfront与接收线程之间存储所述接收线程的模式可以通过Xenstore实现，Xenstore是一个位于Dom0的树状数据库，存储了所有正在运行的DomU的配置信息。因此可以在Xenstore中设置固定的键值来对应接收线程应该所处的模式。当接收线程从接收线程与netback之间的共享变量中读取到所述接收线程需处于的模式发生变化时，在Xenstore修改标识所述接收线程的键值。

同时Xenstore提供一种“watch”监听机制，即当所接收线程在Xenstore修改标识所述接收线程的模式的键值后，触发Xenstore向netfront发送通知信息，该通知信息用于通知所述接收线程的所处的模式发生了变化。具体通知netfront所述接收线程是由非轮询模式变为轮询模式，还是有轮询模式变为非轮询模式。

在所述接收线程通过eventchannel发送通知消息来通知DomU的netfront有数据需要处理时，netfront读取I/O环，对数据响应中携带的内存地址所存储的数据进行处理。netfront处理一个数据响应后，则会再次申请内存空间，并将申请的内存空间的内存地址携带在数据请求(req)中放置到I/O环上。

具体的，DomU的netfront进行如下处理，如图5所示。

S501，DomU的netfront生成第一数据请求放置在所述netfront与Dom0的netback之间的I/O环。

S502，DomU的netfront确定Dom0的接收线程所处的模式为轮询模式时，无需向所述Dom0的接收线程发送唤醒请求。

所述轮询模式用于标识接收线程处于非休眠状态。

由于接收线程，在确定自身所处的模式发生变化时，已经通知netfront所述接收线程是由非轮询模式变为轮询模式，还是有轮询模式变为非轮询模式。因此，netfront可以将所述接收线程的模式存储下来。从而netfront生成第一数据请求放置在所述netfront与netback之间的I/O环之后，读取自身存储的所述接收线程的模式，在确定读取到所述接收线程的模式为轮询模式时，无需向所述Dom0的接收线程发送唤醒请求，从而能够避免domU的频繁退出造成的前后端接收性能低下。

可选的，所述netfront生成第二数据请求放置在所述netfront与Dom0的netback之间的I/O环后，所述netfront接收到所述接收线程发送的用于通知所述接收线程的模式由轮询模式更改为非轮询模式的通知信息时，所述netfront向所述接收线程发送用于唤醒所述接收线程的唤醒请求。

netfront接收到所述接收线程发送的用于通知所述接收线程的模式由轮询模式更改为非轮询模式的通知信息时，确定了所述接收线程的模式由轮询模式更改为非轮询模式，也就是接收线程此刻处于非轮询模式了，因此不能确定此刻所述接收线程是否休眠了，所述netfront需要向所述接收线程发送用于唤醒所述接收线程的唤醒请求。

Dom0的netback接收虚拟机监控器VMM的事件通道发来的第一数据包，现有技术中netback不知道接收线程是否休眠，因此所述netback将接收到的所述第一数据包处理后存储在网络套接字包缓存skb队列之中，需要唤醒接收线程，但利用本发明实施例提供的方案，所述netback在确定所述Dom0的接收线程所处的模式为轮询模式时，确定了接收线程目前处于非休眠状态，因此无需唤醒所述接收线程，所述轮询模式用于标识接收线程处于非休眠状态，从而避免了netback频繁唤醒接收线程。

在DomU的netfront生成第一数据请求放置在所述netfront与Dom0的netback之间的I/O环后，现有技术中DomU的netfront不知道接收线程此刻是否休眠，因此需要唤醒接收线程，利用本发明实施例提供的方案，确定Dom0的接收线程所处的模式为轮询模式时，确定了接收线程此刻处于非休眠状态，因此无需向所述Dom0的接收线程发送唤醒请求，从而避免了DomU频繁的退出。

基于与图3对应的方法实施例同样的发明构思，本发明实施例还提供了一种虚拟化平台中的数据处理装置，如图6所示，所述数据处理装置应用于特权虚拟机Dom0的后端驱动，该装置包括：

接收单元601，用于接收VMM的事件通道发来的第一数据包；

处理单元602，用于将所述接收单元601接收到的所述第一数据包处理后存储在skb队列后，在确定所述Dom0的接收线程所处的模式为轮询模式时，无需唤醒所述接收线程，所述轮询模式用于标识接收线程处于非休眠状态。

可选地，所述处理单元602，在确定所述接收线程所处的模式为轮询模式具体可以通过如下方式实现：

第一种实现方式：

在被允许读取所述接收线程所处的模式时，读取所述接收线程所处的模式为轮询模式。

第二种实现方式：

在被禁止读取所述接收线程所处的模式时，则等待预定时间后，再次尝试读取所述接收线程所处的模式，直到被允许且读取到所述接收线程所处的模式为轮询模式。

可选地，所述处理单元602在确定所述Dom0的接收线程所处的模式为轮询模式之后，还用于：

在确定skb队列中的剩余内存空间不小于第二空间阈值且确定接收线程处于所述轮询模式的时间达到时间阈值时，将所述接收线程所处的模式由所述轮询模式修改为所述非轮询模式，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在用户虚拟机DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。

可选地，所述接收单元601，还用于接收VMM的事件通道发送的第二数据包；

所述处理单元602，还用于将所述接收单元601接收到的所述第二数据包处理后存储在skb队列中之后，在确定skb队列中的剩余内存空间小于第一空间阈值且确定所述接收线程所处的模式为非轮询模式时，将所述接收线程所处的模式由非轮询模式修改为轮询模式，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在用户虚拟机DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态；唤醒所述接收线程。

可选地，所述处理单元602，还用于在对所述接收线程所处的模式修改时，对所述接收线程所处的模式设置写锁，所述写锁用于禁止其他后端驱动以及所述接收线程读取所述接收线程所处的模式，并在对所述接收线程所处的模式修改完成后，解除所述写锁。

本发明实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本申请各个实施例中的各功能单元可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

其中，集成的单元既可以采用硬件的形式实现时，如图7所示，接收单元601对应的实体的硬件为通信接口701，处理单元602对应的实体硬件为处理器702。处理器702，可以是一个中央处理单元(英文：centralprocessingunit，简称CPU)，或者为数字处理单元等等。

其中，该数据处理装置还包括：存储器703，用于存储处理器702执行的程序。处理器702用于执行存储器703存储的程序，具体用于处理单元602以及接收单元601执行的方案。存储器703还可以用于存储skb队列。

本发明实施例中不限定上述通信接口701、处理器702以及存储器703之间的具体连接介质。本发明实施例在图7中以存储器703、处理器702以及通信接口701之间通过总线704连接，总线在图7中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器703可以是易失性存储器(英文：volatilememory)，例如随机存取存储器(英文：random-accessmemory，缩写：RAM)；存储器也可以是非易失性存储器(英文：non-volatilememory)，例如只读存储器(英文：read-onlymemory，缩写：ROM)，快闪存储器(英文：flashmemory)，硬盘(英文：harddiskdrive，缩写：HDD)或固态硬盘(英文：solid-statedrive，缩写：SSD)、或者存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是上述存储器的组合。

基于与图4所示的方法实施例同样的发明构思，本发明实施例还提供了一种虚拟化平台中的数据处理装置，所述数据处理装置应用于Dom0的接收线程，如图8所示，该数据处理装置包括：

确定单元801，用于在尝试对skb队列中的数据包进行处理时，确定skb队列是否为空或者确定DomU的前端驱动与所述Dom0的后端驱动之间的共享内存是否为满；

所述读取单元802，在确定skb队列为空或者确定用户虚拟机DomU的前端驱动与所述特权虚拟机Dom0的后端驱动之间的共享内存为满时，读取所述接收线程需处于的模式；并在读取到所述模式为轮询模式时，所述接收线程无需休眠；所述轮询模式用于标识接收线程处于非休眠状态。

可选地，所述确定单元801，还用于在所述读取单元802读取到所述模式为轮询模式后，确定上一次读取到的所述接收线程需处于的模式；

还包括：

第一通知单元803，在确定单元801确定上一次读取到的所述接收线程需处于的模式为非轮询模式时，向用户虚拟机DomU的前端驱动发送用于通知所述接收线程的模式由非轮询模式更改为轮询模式的通知信息。

其中，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。

可选地，所述读取单元802，在读取所述接收线程需处于的模式，具体用于在被允许读取所述接收线程需处于的模式时，读取所述接收线程需处于的模式。

可选地，所述读取单元802，在读取所述接收线程需处于的模式，具体用于：

在被禁止读取所述接收线程需处于的模式时，则等待预定时间后，再次尝试读取所述接收线程需处于的模式，直到被允许读取所述接收线程需处于的模式。

可选地，该数据处理装置还可以包括：

第二通知单元804，用于在所述确定单元801确定skb队列为空或者确定DomU的前端驱动与所述Dom0的后端驱动之间的共享内存为满之后，所述读取单元802读取到所述接收线程需处于非轮询模式且所述确定单元801确定上一次读取到所述接收线程需处于的模式为轮询模式时，向所述前端驱动发送用于通知所述接收线程的模式由轮询模式更改为非轮询模式的通知信息。

本发明实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本申请各个实施例中的各功能单元可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

其中，集成的单元既可以采用硬件的形式实现时，如图9所示，第一通知单元803以及第二通知单元804对应的实体的硬件为通信接口901，确定单元801、读取单元802对应的实体硬件为处理器902。处理器902，可以是一个CPU，或者为数字处理单元等等。

其中，该数据处理装置还包括：存储器903，用于存储处理器902执行的程序。处理器902用于执行存储器903存储的程序。

本发明实施例中不限定上述通信接口901、处理器902以及存储器903之间的具体连接介质。本发明实施例在图9中以存储器903、处理器902以及通信接口901之间通过总线904连接，总线在图9中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器903可以是volatilememory，例如RAM；存储器903也可以是非易失性存储器，例如ROM，flashmemory，HDD或SSD、或者存储器903是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器903可以是上述存储器的组合。

基于与图5所示的方法实施例同样的发明构思，本发明实施例还提供了一种虚拟化平台中的数据处理装置，所述数据处理装置应用于DomU的前端驱动，如图10所示，该数据处理装置包括：

处理单元1001，用于生成第一数据请求并放置在所述前端驱动与特权虚拟机Dom0的后端驱动之间的共享内存；

发送单元1002，用于在所述处理单元1001确定特权虚拟机Dom0的接收线程所处的模式为轮询模式时，无需向所述Dom0的接收线程发送唤醒请求，所述轮询模式用于标识接收线程处于非休眠状态。

可选地，所述处理单元1001，还用于生成第二数据请求放置在所述前端驱动与所述后端驱动之间的共享内存；

还包括：

接收单元1003，用于接收所述接收线程发送的用于通知所述接收线程的模式由轮询模式更改为非轮询模式的通知信息；

所述发送单元1002，还用于在所述接收单元1003接收到所述通知信息时，向所述接收线程发送用于唤醒所述接收线程的唤醒请求，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在用户虚拟机DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。

本发明实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本申请各个实施例中的各功能单元可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

其中，集成的单元既可以采用硬件的形式实现时，如图11所示，接收单元1003以及发送单元1002对应的实体的硬件为通信接口1101，处理单元1001、对应的实体硬件为处理器1102。处理器1102，可以是一个CPU，或者为数字处理单元等等。

其中，该数据处理装置还包括：存储器1103，用于存储处理器1102执行的程序。处理器1102用于执行存储器1103存储的程序。

本发明实施例中不限定上述通信接口1101、处理器1102以及存储器1103之间的具体连接介质。本发明实施例在图11中以存储器1103、处理器1102以及通信接口1101之间通过总线1104连接，总线在图11中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器1103可以是volatilememory，例如RAM；存储器1103也可以是非易失性存储器，例如ROM，flashmemory，HDD或SSD、或者存储器1103是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器1103可以是上述存储器的组合。

其中，本发明实施例中处理器702、处理器902、处理器1102可以为同一个处理器，也可以为不同的处理器。存储器703、存储器903、存储器1103可以为同一个存储器，也可以为不同的存储器，用于保存skb队列，以及共享内存以及xenstore等等。

Dom0的后端驱动接收VMM的事件通道发来的第一数据包，现有技术中后端驱动不知道接收线程是否休眠，因此所述后端驱动将接收到的所述第一数据包处理后存储在网络套接字包缓存skb队列之中，需要唤醒接收线程，但利用本发明实施例提供的方案，所述后端驱动在确定所述Dom0的接收线程所处的模式为轮询模式时，确定了接收线程目前处于非休眠状态，因此无需唤醒所述接收线程，所述轮询模式用于标识接收线程处于非休眠状态，从而避免了后端驱动频繁唤醒接收线程。

在DomU的前端驱动生成第一数据请求放置在所述前端驱动与Dom0的后端驱动之间的共享内存后，现有技术中DomU的前端驱动不知道接收线程此刻是否休眠，因此需要唤醒接收线程，利用本发明实施例提供的方案，确定Dom0的接收线程所处的模式为轮询模式时，确定了接收线程此刻处于非休眠状态，因此无需向所述Dom0的接收线程发送唤醒请求，从而避免了DomU频繁的退出。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (26)

1.一种虚拟化平台中的数据处理方法，其特征在于，包括：

特权虚拟机Dom0的后端驱动接收虚拟机监控器VMM的事件通道发来的第一数据包；

所述后端驱动将接收到的所述第一数据包处理后存储在网络套接字包缓存skb队列后，在确定所述Dom0的接收线程所处的模式为轮询模式时，无需唤醒所述接收线程，所述轮询模式用于标识接收线程处于非休眠状态。

2.如权利要求1所述的方法，其特征在于，所述后端驱动确定所述接收线程所处的模式为轮询模式，包括：

所述后端驱动在被允许读取所述接收线程所处的模式时，读取所述接收线程所处的模式为轮询模式。

3.如权利要求1所述的方法，其特征在于，所述后端驱动确定所述接收线程所处的模式为轮询模式，包括：

所述后端驱动在被禁止读取所述接收线程所处的模式时，则等待预定时间后，再次尝试读取所述接收线程所处的模式，直到被允许且读取到所述接收线程所处的模式为轮询模式。

4.如权利要求1至3任一项所述的方法，其特征在于，所述后端驱动在确定所述Dom0的接收线程所处的模式为轮询模式之后，还包括：

在确定skb队列中的剩余内存空间不小于第二空间阈值且确定接收线程处于所述轮询模式的时间达到时间阈值时，将所述接收线程所处的模式由所述轮询模式修改为所述非轮询模式，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在用户虚拟机DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。

5.如权利要求1所述的方法，其特征在于，还包括：

所述后端驱动接收VMM的事件通道发送的第二数据包；

所述后端驱动将接收到的所述第二数据包处理后存储在skb队列中之后，在确定skb队列中的剩余内存空间小于第一空间阈值且确定所述接收线程所处的模式为非轮询模式时，将所述接收线程所处的模式由非轮询模式修改为轮询模式，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在用户虚拟机DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态；

所述后端驱动唤醒所述接收线程。

6.如权利要求4或5所述的方法，其特征在于，还包括：

所述后端驱动在对所述接收线程所处的模式修改时，对所述接收线程所处的模式设置写锁，所述写锁用于禁止其他后端驱动以及所述接收线程读取所述接收线程所处的模式，并

在对所述接收线程所处的模式修改完成后，解除所述写锁。

7.一种虚拟化平台中的数据处理方法，其特征在于，包括：

特权虚拟机Dom0的接收线程尝试对网络套接字包缓存skb队列中的数据包进行处理时，确定skb队列为空或者确定用户虚拟机DomU的前端驱动与所述特权虚拟机Dom0的后端驱动之间的共享内存为满时，读取所述接收线程需处于的模式；

所述接收线程在读取到所述模式为轮询模式时，无需休眠；所述轮询模式用于标识接收线程处于非休眠状态。

8.如权利要求7所述的方法，其特征在于，所述接收线程在读取到所述模式为轮询模式后，还包括：

所述接收线程确定上一次读取到的所述接收线程需处于的模式为非轮询模式时，所述接收线程向用户虚拟机DomU的前端驱动发送用于通知所述接收线程的模式由非轮询模式更改为轮询模式的通知信息；

所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在用户虚拟机DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。

9.如权利要求7或8所述的方法，其特征在于，所述接收线程读取所述接收线程需处于的模式，包括：

所述接收线程在被允许读取所述接收线程需处于的模式时，读取所述接收线程需处于的模式。

10.如权利要求7或8所述的方法，其特征在于，所述接收线程读取所述接收线程需处于的模式，包括：

所述接收线程在被禁止读取所述接收线程需处于的模式时，则等待预定时间后，再次尝试读取所述接收线程需处于的模式，直到被允许读取所述接收线程需处于的模式。

11.如权利要求7至10任一项所述的方法，其特征在于，所述接收线程确定skb队列为空或者确定用户虚拟机DomU的前端驱动与所述特权虚拟机Dom0的后端驱动之间的共享内存为满之后，还包括：

所述接收线程读取到所述接收线程需处于非轮询模式且确定上一次读取到所述接收线程需处于的模式为轮询模式时，向所述前端驱动发送用于通知所述接收线程的模式由轮询模式更改为非轮询模式的通知信息。

12.一种虚拟化平台中的数据处理方法，其特征在于，包括：

用户虚拟机DomU的前端驱动生成第一数据请求放置在所述前端驱动与特权虚拟机Dom0的后端驱动之间的共享内存；

用户虚拟机DomU的前端驱动确定特权虚拟机Dom0的接收线程所处的模式为轮询模式时，无需向所述Dom0的接收线程发送唤醒请求，所述轮询模式用于标识接收线程处于非休眠状态。

13.如权利要求12所述的方法，其特征在于，还包括：

所述前端驱动生成第二数据请求放置在所述前端驱动与特权虚拟机Dom0的后端驱动之间的共享内存；

所述前端驱动接收到所述接收线程发送的用于通知所述接收线程的模式由轮询模式更改为非轮询模式的通知信息时，所述前端驱动向所述接收线程发送用于唤醒所述接收线程的唤醒请求，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在用户虚拟机DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。

14.一种虚拟化平台中的数据处理装置，其特征在于，所述数据处理装置应用于特权虚拟机Dom0的后端驱动，包括：

接收单元，用于接收虚拟机监控器VMM的事件通道发来的第一数据包；

处理单元，用于将所述接收单元接收到的所述第一数据包处理后存储在网络套接字包缓存skb队列后，在确定所述Dom0的接收线程所处的模式为轮询模式时，无需唤醒所述接收线程，所述轮询模式用于标识接收线程处于非休眠状态。

15.如权利要求14所述的装置，其特征在于，所述处理单元，在确定所述接收线程所处的模式为轮询模式具体用于：

在被允许读取所述接收线程所处的模式时，读取所述接收线程所处的模式为轮询模式。

16.如权利要求14所述的装置，其特征在于，所述处理单元，在确定所述接收线程所处的模式为轮询模式时，具体用于：

在被禁止读取所述接收线程所处的模式时，则等待预定时间后，再次尝试读取所述接收线程所处的模式，直到被允许且读取到所述接收线程所处的模式为轮询模式。

17.如权利要求14至16任一项所述的装置，其特征在于，所述处理单元在确定所述Dom0的接收线程所处的模式为轮询模式之后，还用于：

在确定skb队列中的剩余内存空间不小于第二空间阈值且确定接收线程处于所述轮询模式的时间达到时间阈值时，将所述接收线程所处的模式由所述轮询模式修改为所述非轮询模式，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在用户虚拟机DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。

18.如权利要求14所述的装置，其特征在于，所述接收单元，还用于接收VMM的事件通道发送的第二数据包；

所述处理单元，还用于将所述接收单元接收到的所述第二数据包处理后存储在skb队列中之后，在确定skb队列中的剩余内存空间小于第一空间阈值且确定所述接收线程所处的模式为非轮询模式时，将所述接收线程所处的模式由非轮询模式修改为轮询模式，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在用户虚拟机DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态；唤醒所述接收线程。

19.如权利要求17或18所述的装置，其特征在于，所述处理单元，还用于在对所述接收线程所处的模式修改时，对所述接收线程所处的模式设置写锁，所述写锁用于禁止其他后端驱动以及所述接收线程读取所述接收线程所处的模式，并

在对所述接收线程所处的模式修改完成后，解除所述写锁。

20.一种虚拟化平台中的数据处理装置，其特征在于，所述数据处理装置应用于特权虚拟机Dom0的接收线程，包括：

确定单元，用于在尝试对网络套接字包缓存skb队列中的数据包进行处理时，确定skb队列是否为空或者确定用户虚拟机DomU的前端驱动与所述特权虚拟机Dom0的后端驱动之间的共享内存是否为满；

所述读取单元，在确定skb队列为空或者确定用户虚拟机DomU的前端驱动与所述特权虚拟机Dom0的后端驱动之间的共享内存为满时，读取所述接收线程需处于的模式；并在读取到所述模式为轮询模式时，所述接收线程无需休眠；所述轮询模式用于标识接收线程处于非休眠状态。

21.如权利要求20所述的装置，其特征在于，所述确定单元，还用于在所述读取单元读取到所述模式为轮询模式后，确定上一次读取到的所述接收线程需处于的模式；

还包括：

第一通知单元，在确定上一次读取到的所述接收线程需处于的模式为非轮询模式时，向用户虚拟机DomU的前端驱动发送用于通知所述接收线程的模式由非轮询模式更改为轮询模式的通知信息；

所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在用户虚拟机DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。

22.如权利要求20或21所述的装置，其特征在于，所述读取单元，在读取所述接收线程需处于的模式，具体用于在被允许读取所述接收线程需处于的模式时，读取所述接收线程需处于的模式。

23.如权利要求20或21所述的装置，其特征在于，所述读取单元，在读取所述接收线程需处于的模式，具体用于：

在被禁止读取所述接收线程需处于的模式时，则等待预定时间后，再次尝试读取所述接收线程需处于的模式，直到被允许读取所述接收线程需处于的模式。

24.如权利要求20至23任一项所述的装置，其特征在于，还包括：

第二通知单元，用于在所述确定单元确定skb队列为空或者确定用户虚拟机DomU的前端驱动与所述特权虚拟机Dom0的后端驱动之间的共享内存为满之后，所述读取单元读取到所述接收线程需处于非轮询模式且所述确定单元确定上一次读取到所述接收线程需处于的模式为轮询模式时，向所述前端驱动发送用于通知所述接收线程的模式由轮询模式更改为非轮询模式的通知信息。

25.一种虚拟化平台中的数据处理装置，其特征在于，所述数据处理装置应用于用户虚拟机DomU的前端驱动，包括：

处理单元，用于生成第一数据请求并放置在所述前端驱动与特权虚拟机Dom0的后端驱动之间的共享内存；

发送单元，用于在所述处理单元确定特权虚拟机Dom0的接收线程所处的模式为轮询模式时，无需向所述Dom0的接收线程发送唤醒请求，所述轮询模式用于标识接收线程处于非休眠状态。

26.如权利要求25所述的装置，其特征在于，所述处理单元，还用于生成第二数据请求放置在所述前端驱动与所述后端驱动之间的共享内存；

还包括：

接收单元，用于接收所述接收线程发送的用于通知所述接收线程的模式由轮询模式更改为非轮询模式的通知信息；

所述发送单元，还用于在所述接收单元接收到所述通知信息时，向所述接收线程发送用于唤醒所述接收线程的唤醒请求，所述非轮询模式用于标识所述接收线程在所述skb队列为空或者在用户虚拟机DomU的前端驱动与所述后端驱动之间的共享内存为满时处于休眠状态。