CN110489358B - 一种交互控制方法及设备系统 - Google Patents

Abstract

本申请公开了一种交互控制方法，应用于设备系统，所述设备系统包括处理器和设备，所述处理器上设置有驱动组件，所述驱动组件与设备之间通过virtio接口进行通信，所述virtio接口为基于virtio协议实现的接口，所述方法包括：所述设备通过所述virtio接口向所述驱动组件发送第一通知消息；所述驱动组件通过所述virtio接口向所述设备发送第二通知消息。可见，本申请中针对处理器上的驱动组件和设备，通过基于virtio协议的virtio接口允许双方向对方发送通知消息，而不受对方的控制影响，由此避免了双方之间进行通知协商所造成的性能和资源消耗，由此达到本申请目的。

Description

一种交互控制方法及设备系统

技术领域

本申请涉及硬件接口技术领域，尤其涉及一种交互控制方法及设备系统。

背景技术

在服务器等设备中，网卡、硬盘等设备对于服务器的中央处理器CPU(CentralProcessing Unit)来说，是一个输入输出IO(Input/Output)设备。

例如，在CPU与网卡的通信中，是通过网卡驱动来实现的。上层应用程序通过调用网卡驱动的应用程序编程接口API(Application Programming Interface)接口实现基于网卡的网络通信。而Virtio是一种设备访问接口，实现基于Virtio的驱动和基于Virtio的设备之间的通信。而由于在硬件实现情况下，需要数据在内存和IO设备之间实际的搬移，因此，在驱动和设备之间的交互中，需要尽量降低资源消耗。

因此，亟需一种能够减少驱动和设备之间交互的资源消耗的技术方案。

发明内容

有鉴于此，本申请提供一种交互控制方法及设备系统，用以减少驱动与设备之间交互的资源消耗。

本申请提供了一种交互控制方法，应用于设备系统，所述设备系统包括处理器和设备，所述处理器上设置有驱动组件，所述驱动组件与设备之间通过virtio接口进行通信，所述virtio接口为基于virtio协议实现的接口，所述方法包括：

所述设备通过所述virtio接口向所述驱动组件发送第一通知消息；

所述驱动组件通过所述virtio接口向所述设备发送第二通知消息。

上述方法，优选的，所述设备通过所述virtio接口向所述驱动组件发送第一通知消息，包括：

所述设备在预设的第一发送条件满足的情况下通过所述virtio接口发送第一通知消息。

上述方法，优选的，所述驱动组件通过所述virtio接口向所述设备发送第二通知消息，包括：

所述驱动组件在预设的第二发送条件满足的情况下通过所述virtio接口发送第二通知消息。

上述方法，优选的，所述方法还包括：

所述驱动组件向所述设备发送通知禁发信息；

所述设备在接收到所述通知禁发信息之后，基于待传输的第一通知消息通过所述virtio接口向共享的描述符队列中写入相应的通知状态信息，所述共享的描述符队列设置在所述处理器对应的内存中；

所述驱动组件在所述共享的描述符队列中读取所述通知状态信息，根据预设的第一处理条件进行相应的处理。

上述方法，优选的，所述第一处理条件包括：

在所述驱动组件向所述设备传输数据的情况下，所述共享的描述符队列存在已处理但未释放的队列项，并且空闲的队列项的数量低于设定的阈值；所述队列项中存储所述通知状态信息；

在所述设备向所述驱动组件传输数据的情况下，所述共享的描述符队列存在已就绪但未处理的队列项并且其数量超过阈值。

本申请还提供了一种设备系统，所述设备系统包括处理器和设备，所述处理器上设置有驱动组件，所述驱动组件与设备之间通过virtio接口进行通信，所述virtio接口为基于virtio协议实现的接口，其中：

所述设备被配置为：所述设备通过所述virtio接口向所述驱动组件发送第一通知消息；

所述驱动组件被配置为：所述驱动组件通过所述virtio接口向所述设备发送第二通知消息。

上述系统，优选的，其中：

所述设备被配置为：所述设备在预设的第一发送条件满足的情况下通过所述virtio接口发送第一通知消息。

上述系统，优选的，其中：

所述驱动组件被配置为：所述驱动组件在预设的第二发送条件满足的情况下通过所述virtio接口发送第二通知消息。

上述系统，优选的，其中：

所述驱动组件被配置为：所述驱动组件向所述设备发送通知禁发信息，以使得所述设备在接收到所述通知禁发信息之后，基于待传输的第一通知消息通过所述virtio接口向共享的描述符队列中写入相应的通知状态信息，所述共享的描述符队列设置在所述处理器对应的内存中；

所述驱动组件进一步被配置为：所述驱动组件在所述共享的描述符队列中读取所述通知状态信息，根据预设的第一处理条件进行相应的处理。

由上述方案可知，本申请提供的一种交互控制方法及设备系统，在处理器上的驱动组件与设备之间进行交互时，通过virtio接口实现通知消息的传输，例如，对于设备来说，设备可以通过virtio接口向驱动组件发送第一通知消息，而不受驱动组件的控制，对于驱动组件来说，驱动组件可以通过virtio接口向设备发送第二通知消息而不受设备的控制。可见，本申请中针对处理器上的驱动组件和设备，通过基于virtio协议的virtio接口允许双方向对方发送通知消息，而不受对方的控制影响，由此避免了双方之间进行通知协商所造成的资源消耗，由此达到本申请目的。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例一提供的一种交互控制方法的实现流程图；

图2为本申请实施例一提供的一种交互控制方法的实现流程图；

图3为本申请实施例二提供的一种设备系统的结构示意图；

图4-图6分别为本申请实施例的相关示例图。

具体实施方式

本申请发明人经过研究发现：虚拟化技术大概分为三类：纯软件模拟的虚拟化，性能最差；类虚拟化(para-virtualization)性能居中；全硬件虚拟化性能最好。在计算机虚拟化技术的发展过程中，处理器已经完全硬件虚拟化，内存也已经完全硬件虚拟化，但是IO设备大部分是基于QEMU全软件模拟设备或类虚拟化Virtio技术的解决方案。随着计算机技术的进一步发展，云计算数据中心对服务器和高速网络、高速存储的要求越来越高，而处理器的性能提升却越来越慢。这样，Virtio类虚拟化IO设备的性能越来越成为IO路径性能的瓶颈，无法满足未来数据中心对IO设备的各项性能指标要求。

为此，在提高传输性能，需要在支持SR-IOV技术的基础上行，克服类虚拟化本身的性能限制，实现IO硬件虚拟化，达到物理IO设备的性能极限；并且需要实现一个支持Virtio接口的硬件设备引擎，标准化硬件访问接口，并且能够支持Virtio-net、Virtio-blk等的设备接口扩展，达到完全统一的硬件访问接口，实现数据中心的高效运维和管理；另外，也要支持Virtio 1.1标准，实现硬件接口能够实现高效的数据传输以及简洁的设计。Virtio1.1相比Virtio1.0有了很大的改动，增加了许多面向硬件优化的features，例如packedvirtqueue、in order queue等特性。

而本申请发明人经过进一步研究发现：在基于硬件化的virtio接口的基础上，对处理器驱动组件与设备之间的通知传输进行非抑制、自优化、异步机制，能够减少两者之间进行通知协商所引起的性能和资源消耗，从而能够达到改善传输性能的目的。

其中，Virtio协议描述的是可协商的驱动-设备交互机制，为了减少Notification的资源消耗，得到更好的性能，Virtio提出了Notification抑制机制。而本申请发明人在符合Virtio协议的基础上优化了此Notification，定义并实现了一种非抑制、自优化、异步的通知机制。

而Virtio的通知优化机制，本质上是双方协商告诉对方自己是否空闲可服务。当设备device可以服务的时候，告诉驱动组件driver现在设备空闲了可以提供服务了，当设备device忙碌的时候，告诉驱动组件driver不要发通知；反之，driver告诉device的通知也是一样。

综上，本申请发明人提出以下方案：

参考图1，为本申请实施例一提供的一种交互控制方法的实现流程图，该方法可以适用于具有处理器和设备的设备系统，如计算机或服务器等，该处理器上设置有驱动组件，驱动组件与设备之间通过virtio接口进行通信，其中，virtio接口为基于virtio协议实现的接口，本实施例中的virtio协议可以是virtio各版本的标准协议。

在本实施例中，该方法可以包括以下步骤：

步骤101：设备通过virtio接口向驱动组件发送第一通知消息。

其中，在设备向驱动组件通过virtio接口发送第一通知消息时，驱动组件不会对设备的发送进行控制，如不禁止或者抑制设备向驱动组件通过virtio接口发送第一通知消息。

需要说明的是，第一通知消息在发送到驱动组件之后，驱动组件可以按照自身的需求决定是否对第一通知消息进行响应，这里的响应可以理解为：驱动组件中断并对该第一通知消息进行处理。

步骤102：驱动组件通过virtio接口向设备发送第二通知消息。

其中，在驱动组件向设备通过virtio接口发送第二通知消息时，设备不会对驱动组件的发送进行控制，如不禁止或抑制驱动组件向设备通过virtio接口发送第二通知消息。

需要说明的是，第二通知消息在发送到设备之后，设备可以按照自身的需求决定是否对第二通知消息进行响应。

由上述方案可知，本申请实施例一提供的一种交互控制方法，在处理器上的驱动组件与设备之间进行交互时，通过virtio接口实现通知消息的传输，例如，对于设备来说，设备可以通过virtio接口向驱动组件发送第一通知消息，而不受驱动组件的控制，对于驱动组件来说，驱动组件可以通过virtio接口向设备发送第二通知消息而不受设备的控制。可见，本实施例中针对处理器上的驱动组件和设备，通过基于virtio协议的virtio接口允许双方向对方发送通知消息，而不受对方的控制影响，由此避免了双方之间进行通知协商所造成的性能和资源消耗，由此达到本实施例目的。

需要说明的是，本实施例中步骤101和步骤102不限定两者之间的执行顺序，除了在附图中所示的前后执行关系之外，其他执行顺序关系所形成的技术方案均与本申请属于同一发明思想，均在本申请的保护范围内。

在一种实现方式中，步骤101中设备通过所述virtio接口向所述驱动组件发送第一通知消息，具体可以为：

所述设备在预设的第一发送条件满足的情况下通过所述virtio接口发送第一通知消息。

其中，第一发送条件可以为：设备的性能和延迟需求满足发送规则，例如，设备发送第一通知消息所引起的性能消耗和延迟不会对设备的正常运行产生较大的影响等。

相应的，驱动组件对于设备发送的第一通知消息，可以根据自身条件决定何时以及如何进行处理，例如，驱动组件在其空闲资源量高于阈值时在对设备发送的第一通知信息进行响应，如先中断再执行与第一通知消息相对应的操作处理。

而步骤102中所述驱动组件通过所述virtio接口向所述设备发送第二通知消息，具体可以为：

所述驱动组件在预设的第二发送条件满足的情况下通过所述virtio接口发送第二通知消息。

其中，第二发送条件可以为：驱动组件的性能和延迟需求满足发送规则，例如，驱动组件发送第二通知消息所引起的性能消耗和延迟不会对处理器及其驱动组件的正常运行产生较大的影响等。

相应的，设备对驱动组件发送的第二通知消息，可以根据自身条件决定何时以及如何进行处理，例如，设备在其空闲资源量高于阈值时在对驱动发送的第二通知信息进行响应，如执行与第二通知消息相对应的数据写入或读取等操作处理。

也就是说，driver和device之间相互不屏蔽对方发通知，各自想发就发，不需要跟对方协商。而由于发通知是有代价的，不管是driver发通知(写寄存器)给device，还是device发通知(interrupt)给driver。那么，driver和device就根据自身的情况(而不是双方协商)，在满足各自性能和延时的要求的基础上，尽可能少的发通知给对方。

在一种实现方式中，本实施例中还可以有另一种通知机制，如图2中所示：

步骤201：所述驱动组件向所述设备发送通知禁发信息。

其中，通知禁发通知可以通过指令或请求的方式通过virtio接口由驱动组件发送给设备，以通知到设备不要给驱动组件发通知。

步骤202：所述设备接收所述通知禁发信息；

步骤203：设备基于待传输的第一通知消息通过所述virtio接口向共享的描述符队列中写入相应的通知状态信息，所述共享的描述符队列设置在所述处理器对应的内存中，如处理器所在系统的内存区域中。

也就是说，在驱动组件要求设备不要发通知之后，设备在需要进行通知发送时，不会直接将第一通知信息发送给驱动组件，而实际基于该待发送的第一通知消息通过virtio接口向处理器对应的内存中的共享的描述符队列中写入相应的通知状态，如在队列中添加新的队列项，该新添加的队列项即为表征设备需要通知到设备的内容。

步骤204：所述驱动组件在所述共享的描述符队列中读取所述通知状态信息，根据预设的第一处理条件进行相应的处理。

其中，由于共享的描述符队列中可能被写入驱动组件需要进行响应的通知消息对应的内容，为此，驱动组件可以对共享的描述符队列进行监测，在发现需要进行通知处理且驱动组件自身条件满足时，可以在共享的描述符队列中读取到相应的通知状态信息，并根据第一处理条件进行相应的处理。

具体的，第一处理条件可以为：在所述驱动组件向所述设备传输数据的情况下，即tx(transport)下，所述共享的描述符队列存在已处理但未释放的队列项，并且空闲的队列项的数量低于设定的阈值。其中，队列项是指驱动组件需要进行处理的队列项，当队列项被处理如当数据搬运完成后则需要释放已处理的队列项，当空闲的队列项的数量低于设定值时候驱动组件才处理队列项。当还有很多空闲的队列项的时候，释放已使用队列项任务优先级不高，这样处理器可以忙于其他更重要的事情。只有当低于设定阈值也就是此任务优先级提高后，才进行处理，这样能让处理器的处理效率最优。由此，驱动组件在第一处理条件满足即共享的描述符队列中存在已经处理但未释放的队列项且空闲队列项的数量低于阈值时，根据从共享的描述符队列中读取出通知状态信息并进行相应的处理。

另外，第一处理条件也可以为：在所述设备向所述驱动组件传输数据的情况下，即rx(receive)下，所述共享的描述符队列存在已就绪但未处理的队列项并且其数量超过阈值。其中，在Rx下，如果只要存在队列项处理器就去处理可能会很频繁的进行处理，由此影响处理器对其他任务的处理，而堆积太多未处理的队列项会影响Rx数据处理的延迟，由此，在本实施例中对第一处理条件中设定一个可接受的阈值，在队列项的数量超过阈值处理器再去处理是最合适的。此时，驱动组件根据从共享的描述符队列中读取出通知状态信息并进行相应的处理。

参考图3，为本申请实施例二提供的一种设备系统的结构示意图，该设备系统中可以包括处理器301和设备302，所述处理器301上设置有驱动组件311，所述驱动组件311与设备302之间通过virtio接口303进行通信，所述virtio接口303为基于virtio协议实现的接口，其中：

所述设备302被配置为：所述设备302通过所述virtio接口303向所述驱动组件311发送第一通知消息；

所述驱动组件311被配置为：所述驱动组件311通过所述virtio接口303向所述设备302发送第二通知消息。

具体的，所述设备302被配置为：所述设备302在预设的第一发送条件满足的情况下通过所述virtio接口303向驱动组件311发送第一通知消息。

而所述驱动组件311被配置为：所述驱动组件311在预设的第二发送条件满足的情况下通过所述virtio接口303向设备302发送第二通知消息。

由上述方案可知，本申请实施例二提供的一种设备系统，在处理器上的驱动组件与设备之间进行交互时，通过virtio接口实现通知消息的传输，例如，对于设备来说，设备可以通过virtio接口向驱动组件发送第一通知消息，而不受驱动组件的控制，对于驱动组件来说，驱动组件可以通过virtio接口向设备发送第二通知消息而不受设备的控制。可见，本实施例中针对处理器上的驱动组件和设备，通过基于virtio协议的virtio接口允许双方向对方发送通知消息，而不受对方的控制影响，由此避免了双方之间进行通知协商所造成的资源消耗，由此达到本实施例目的。

在一种实现方式中，所述驱动组件311可以被配置为：所述驱动组件311向所述设备302发送通知禁发信息，以使得所述设备302在接收到所述通知禁发信息之后，基于待传输的第一通知消息通过所述virtio接口303向共享的描述符队列中写入相应的通知状态信息，所述共享的描述符队列设置在所述处理器301对应的内存中；

所述驱动组件311进一步被配置为：所述驱动组件311在所述共享的描述符队列中读取所述通知状态信息，根据预设的第一处理条件进行相应的处理。

具体的，所述第一处理条件可以为：

在所述驱动组件向所述设备传输数据的情况下，所述共享的描述符队列存在已处理但未释放的队列项，并且空闲的队列项的数量低于设定的阈值；所述队列项中存储所述通知状态信息；

在所述设备向所述驱动组件传输数据的情况下，所述共享的描述符队列存在已就绪但未处理的队列项并且其数量超过阈值。

为了便于理解，以下对本实施例中的技术方案在具体实现中的应用进行举例说明：

以网卡为例，网卡相对服务器CPU来说，是一个IO设备Device。CPU和网卡的通信，是通过网卡driver来完成的，上层的应用程序通过调用driver的API接口来实现基于网卡的网络通信。Virtio是一种设备访问接口，实现Virtio driver和Virtio device的通信，本实施例中把Virtio device里实现与Virtio接口的部分称为Virtio引擎模块，把其中与设备相连接的部分称为virtio设备类型连接模块即virtio-type模块，即：virtio接口包括Virtio引擎模块和virtio-type模块。基于virtio接口，可以实现virtio-net、virtio-blk、virtio-console等各种不同的设备类型接口，本实施例中用Virtio-type来表述基于Virtio接口实现的各种不同Virtio设备类型。

Virtio本质是驱动和设备按照协商好的一个交互接口。虚拟化场景下，数据从Host到Guest或者从Guest到Host不涉及到实际的数据搬移，只是通过内存管理机制更新一下内存的权限属性。但在硬件实现情况下，则需要数据在Host内存和IO设备内存之间实际的搬移，高效的DMA处理成为Virtio设备性能的关键。

如图4所示基于生产者和消费者模型的Virtio设备和驱动在tx和rx两种情况下的交互流程，基于图4的操作结合图5中结构，在不考虑通知优化的情况下，本实施例中可以把驱动和设备的交互简单总结为如表1中所示：

表1

如图5中virtio接口的电路结构所示，连接PCIe SR-IOV的virtio接口以硬件化的virtio设备实现，包括与stream总线连接的virtio引擎(包括virtio寄存器和virtio控制器)和virtio-type模块，virtio-type模块用于连接processor subsystem，以实现后续具体的数据处理，核心是DMA引擎(包含描述符引擎、host-dev DMA引擎和dev-host DMA引擎)来实现数据搬移。控制流程可以通过软件实现：通过一个polling机制的程序专门负责用Virtio Reg的配置信息更新DMA描述符的处理，同时也负责检测DMA处理的状态，反过来更新Virtio的状态寄存器。

在本实施例中，Virtio协议描述的是可协商的驱动-设备交互机制，为了减少Notification的资源消耗，得到更好的性能，本实施例中基于Virtio提出了Notification抑制机制。由此，本实施例中可以在符合Virtio协议的基础上优化了此Notification，定义并实现了一种非抑制、自优化、异步的通知机制。

其中，Virtio的通知优化机制，本质上是双方协商告诉对方自己是否空闲可服务。当device可以服务的时候，告诉driver我现在空闲了可以提供服务了，当device忙碌的时候，告诉driver不要发通知；反之，driver告诉device的通知也是一样。

因为本实施例中Virtio是硬件实现，跟传统的Virtio/Vhost的通知机制不一样。基于硬件设备的非抑制、自优化、异步的通知机制体现在：

1、非抑制：就是driver和device之间相互不屏蔽对方发通知，各自想发就发，不需要跟对方协商。

2、自优化：发通知是有代价的，不管是driver发通知(写寄存器)给device，还是device发通知(interrupt)给driver。那么，driver和device就根据自身的情况(而不是双方协商)，在满足各自性能和延时的要求的基础上，尽可能少的发通知给对方。

3、异步：虽然driver和device可以自由的发通知给对方，但device和driver何时处理通知，则是根据自身情况来决定的。具体如下：

3.1驱动通知设备的情况：因为要支持SR-IOV，每个PF/VF还可能有多个Queue，因此硬件设备内部采取轮训或加权轮训的方法响应驱动对设备的通知。驱动可以根据自己的情况，按照一定的节奏发通知给设备，设备响应驱动通知是异步的，按照自己内部的运行机制在合适的时间进行最终的处理。

3.2设备通知驱动的情况：驱动实现方式有两种，interrupt模式和polling模式。

其中，Interrupt模式中：设备根据自身的情况发interrupt给driver端，driver端要是每个interrupt都响应，则代价很大，为此Driver端会根据自身情况disable/enable中断，会在自身空闲的时候主动去处理中断，而不是随时被动的被中断打断。

而polling模式中，为了更好的支持Polling模式下的性能，这里还是用到了通知协商机制。如果driver机制是polling mode，则driver告诉device完全不发中断，这样device端只更新共享的数据结构，在接口上，后续交由polling模式的driver处理，即driver在检测到需要进行处理时，在共享的数据结构(共享的描述符队列，如图6中的生产者producer与消费者consumer模型中的缓存队列shared descriptor queue)中读取device更新的状态，并进行相应的后续处理。

因此，本实施例中通过优化的自定义的协商机制有如下好处：

1、双方不在通知协商上面花代价，即使在polling mode driver的情况下，也只是初始化的时候协商一次，后续不再变化；

2、Host端driver也不存在中断现场切换的各种开销；

具体的，本实施例中通过通知抑制机制实现了通过virtio struct实现了信息的通知。然后是polling mode的driver，主动屏蔽中断。通过polling方式主动处理，所以可以不需要中断，从来避免了中断开销。

3、异步的处理，设备和driver都能达到最优的任务调度处理。在保证符合性能延迟要求下，性能最优；

具体的，本实施例中基于硬件virtio device，这本身就是对传统virtio半虚拟化(para-virtualization)的性能优化。而通知抑制机制实现的通知异步处理，是在运行环境一致的情况下(对比环境都是para-virtualization的性能优化，或者都是硬件virtiodevice情况下)，通过对交互协议的优化，实现性能提升。

4、因为没有了通知协商，设计复杂度也更低。

综上，本实施例中通过IO硬件虚拟化，实现PCIe SR-IOV技术支持。SR-IOV技术是IO硬件虚拟化的必须要支持的，传统的VT-d技术从虚机直接pass through到硬件，只支持一个设备，而本实施例中通过SR-IOV技术的PF/VF可以虚拟出多个设备，这样才能支持多个虚拟机中的多个硬件设备的高效访问。

而且，本实施例中基于标准的硬件访问接口实现Virtio接口访问。其中，本实施例中实现Virtio访问接口，是为了实现硬件接口标准化。因为云计算场景需要管理成千上万台服务器，甚至上百万的虚拟机，需要硬件呈现出标准化的访问接口，也需要把物理的服务器硬件接口和虚拟的虚拟机接口统一起来，这样更有利于管理和调度。

另外，本实施例中通过高效的数据传输接口实现Virtio1.1版本硬件设备，完全兼容Virtio1.1版本的驱动。Virtio1.0是一个软件设计思路的驱动-设备交互协议，硬件实现的复杂度很高，而且数据传输效率却不是很高；而Virtio1.1版本是面向硬件实现优化的版本，性能更高，并且硬件实现更简单高效资源占用少。

最终，本实施例中通过优化的通知抑制机制定义并实现了一种非抑制、自优化、异步的通知机制，以此来减少通知以及通知的代价。达到符合性能延时要求下的整体最优的性能传输。本实施例中以软件处理的方式实现Virtio设备的控制，不影响性能的情况下，达到硬件实现更简单，资源占用更少。

可见，本申请实施例实现了支持IO硬件虚拟化的高效的标准化Virtio硬件访问接口：

1、这样不仅仅可以提升虚拟化场景IO访问的性能，接近甚至达到IO设备的极限性能；

2、还提供了标准化的访问接口，屏蔽了不同厂家不同型号IO设备的接口多样性，并且统一了虚拟机和物理机的访问；

3、通过支持Virtio1.1的各项feature，能够提升IO性能的同时还硬件设计更简单，提升了性能同时降低了硬件成本。

4、优化的通知抑制机制，在符合Virtio协议并灵活支持上层业务场景的同时，尽可能的优化通知的代价，以此降低数据传输的性能损耗。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

以上仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (7)

1.一种交互控制方法，其特征在于，应用于设备系统，所述设备系统包括处理器和设备，所述处理器上设置有驱动组件，所述驱动组件与设备之间通过硬件化的virtio接口进行通信，所述virtio接口为基于包括Notification抑制机制的virtio协议实现的接口，所述方法包括：

所述设备通过所述virtio接口向所述驱动组件发送第一通知消息；

所述驱动组件通过所述virtio接口向所述设备发送第二通知消息；

所述驱动组件向所述设备发送通知禁发信息；

所述设备在接收到所述通知禁发信息之后，基于待传输的第一通知消息通过所述virtio接口向共享的描述符队列中写入相应的通知状态信息，所述共享的描述符队列设置在所述处理器对应的内存中；

所述驱动组件在所述共享的描述符队列中读取所述通知状态信息，根据预设的第一处理条件进行相应的处理。

2.根据权利要求1所述的方法，其特征在于，所述设备通过所述virtio接口向所述驱动组件发送第一通知消息，包括：

所述设备在预设的第一发送条件满足的情况下通过所述virtio接口发送第一通知消息。

3.根据权利要求1所述的方法，其特征在于，所述驱动组件通过所述virtio接口向所述设备发送第二通知消息，包括：

所述驱动组件在预设的第二发送条件满足的情况下通过所述virtio接口发送第二通知消息。

4.根据权利要求1所述的方法，其特征在于，所述第一处理条件包括：

在所述驱动组件向所述设备传输数据的情况下，所述共享的描述符队列存在已处理但未释放的队列项，并且空闲的队列项的数量低于设定的阈值；所述队列项中存储所述通知状态信息；

在所述设备向所述驱动组件传输数据的情况下，所述共享的描述符队列存在已就绪但未处理的队列项并且其数量超过阈值。

5.一种设备系统，其特征在于，所述设备系统包括处理器和设备，所述处理器上设置有驱动组件，所述驱动组件与设备之间通过硬件化的virtio接口进行通信，所述virtio接口为基于包括Notification抑制机制的virtio协议实现的接口，其中：

所述设备被配置为：所述设备通过所述virtio接口向所述驱动组件发送第一通知消息；

所述驱动组件被配置为：所述驱动组件通过所述virtio接口向所述设备发送第二通知消息；所述驱动组件向所述设备发送通知禁发信息，以使得所述设备在接收到所述通知禁发信息之后，基于待传输的第一通知消息通过所述virtio接口向共享的描述符队列中写入相应的通知状态信息，所述共享的描述符队列设置在所述处理器对应内存中；

所述驱动组件进一步被配置为：所述驱动组件在所述共享的描述符队列中读取所述通知状态信息，根据预设的第一处理条件进行相应的处理。

6.根据权利要求5所述的系统，其特征在于，其中：

所述设备被配置为：所述设备在预设的第一发送条件满足的情况下通过所述virtio接口发送第一通知消息。

7.根据权利要求5所述的系统，其特征在于，其中：

所述驱动组件被配置为：所述驱动组件在预设的第二发送条件满足的情况下通过所述virtio接口发送第二通知消息。

Images