WO2017107816A1 - Method of processing data on virtualization platform and device - Google Patents

Abstract

A method of processing data on virtualization platform and device, resolving a problem of low performance of a frontend or a backend of a conventional network resulting from frequently waking up a netfront to receive a thread and frequently demounting a DomU. The method comprises: a netback of a Dom0 receives a first data packet transmitted over an event channel on a virtual machine monitor; and after processing the received first data packet and storing the same in a network socket packet buffering queue, if a mode of a thread received by the Dom0 is determined as a polling mode, the netback is not required to wake up the received thread, wherein the polling mode is used to indicate that the received thread is in a non-sleep mode.

Description

Data processing method and device in virtualization platform

This application claims priority to Chinese Patent Application No. 201510979888.2, entitled "Data Processing Method and Apparatus in a Virtualization Platform", filed on December 23, 2015, the entire contents of which are incorporated by reference. Combined in this application.

Technical field

The present invention relates to the field of communications technologies, and in particular, to a data processing method and apparatus in a virtualization platform.

Background technique

Virtualization technology is a new computing model that supports running multiple isolated virtual environments on a single hardware platform. By deploying different services in these virtual environments, multiple services are aggregated on a single physical node.

Take the open source virtualization product XEN as an example. It includes a virtual machine monitor (English: Virtual Machine Monitor, VMM for short), a privileged virtual machine (Domain 0, Dom0 for short), and multiple guest virtual machines (Domain). U, referred to as: DomU).

The VMM runs between the guest virtual machine and the hardware, and both Dom0 and DomU run on top of the VMM layer. The special feature of Dom0 is that it has management tools for managing other DomUs and interfaces with VMMs to control the virtual environment. The Dom0 side also includes an interface for receiving DomU hardware access information, called a backend driver (netback), and the backend driver can receive hardware requests from all DomUs on the same physical machine. The DomU side also includes an interface to send hardware requests to Dom0, called front-end driver (netfront).

There is a fixed shared memory between Dom0 and DomU, that is, an input/output port (English: input/output, referred to as I/O) ring, which is used to transfer data requests and responses between DomU and Dom0. Dom0 and DomU exchange data requests and responses with each other through the event channel set on the VMM, that is, Dom0 and DomU exchange data requests and responses with each other. Dom0<->VMM<->DomU.

The front-end driver will apply for the memory space in advance, and place the memory address in the data request (English: request, referred to as: req) and place it on the IO ring. The external data packet sent to the virtual machine (that is, the data packet sent to the DomU) first arrives at the physical network card (NIC) managed by the VMM, and the VMM sends an interrupt request to the Dom0 through the event channel. Dom0 will process this interrupt, encapsulate the corresponding data packet as a network socket packet cache (English: Socket Buffer, referred to as: skb), and place it in a skb queue (skb_list) through netback.

Thereafter, a separate kernel receive thread (vif-rx-qX) running on Dom0 will fetch the packet from the skb queue and copy the data included in the packet to the memory carried by the data request (req) on the IO ring. The memory space corresponding to the address, and then the memory address corresponding to the copy data is carried in the data response (English: response, referred to as: rsp) placed on the IO ring before the data request (req) occupied position, and sent through the event channel A notification message to inform DomU's netfront. Netfront will take the data response (rsp) from the IO ring, obtain the data packet stored in the corresponding memory address of the data response, and complete the processing of the data packet. Then, netfront will apply for the memory space again. The memory address carrying the memory space is placed in the data request (req) and placed on the IO ring for the netback to continue to place the data response (req).

It should be noted that in this process, if the netfront processing speed is slow, the IO ring is filled with the data response, and the receiving thread cannot generate a new data response and put it into the IO ring, the receiving thread will be in a waiting state, that is, When the receiving thread sleeps, or there is no data in the skb queue, the receiving thread also sleeps; when the receiving thread sleeps, it does not process the data even if there is data in the skb queue. Therefore, each time a new packet arrives at the physical NIC and is placed by the Dom0 into the skb queue, the netback wakes up the receiving thread so that the receiving thread processes the data in the skb queue. Accordingly, when DomU's netfront reads and processes data from the IO ring, it applies for memory space and generates new data requests for placement on the IO ring. Since netfront is not sure whether the receiving thread is in a dormant state, netfront first needs to notify Dom0 through the event channel to wake up the receiving thread. DomU's every event channel operation will cause DomU to exit, and in the virtualized environment, DomU's frequent exit is exactly what needs to be avoided. Backend drivers frequently wake up the receiving thread and DomU Frequent exits are an important factor in the low performance of the front and back of existing networks.

Summary of the invention

The embodiment of the invention provides a data processing method and device in a virtualization platform, which is used to solve the problem that the back-end driver frequently wakes up the receiving thread and the DomU frequently exits in the prior art, thereby causing low performance of the front and rear ends of the existing network. .

In a first aspect, an embodiment of the present invention provides a data processing method in a virtualization platform, where the method includes:

The backend driver of the Dom0 receives the first data packet sent by the VMM; wherein the VMM sends the first data packet to the backend driver through an event channel between the VMM and the backend driver.

After the first-end data packet is processed and stored in the skb queue, the back-end driver does not need to wake up the receiving thread when determining that the mode in which the receiving thread of the Dom0 is in the polling mode. The polling mode is used to identify that the receiving thread is in a non-sleep state.

In the prior art, the backend driver does not know whether the receiving thread is dormant. Therefore, the backend driver processes the received first data packet and stores it in the skb queue, and needs to wake up the receiving thread, but uses the embodiment of the present invention. The solution provides that when the mode in which the receiving thread of the Dom0 is determined to be in a polling mode, it is determined that the receiving thread is currently in a non-sleep state, so there is no need to wake up the receiving thread, thereby avoiding the back end. The driver frequently wakes up the receiving thread.

In one of the possible designs, the backend driver determines that the mode in which the receiving thread is located is a polling mode, which can be implemented as follows:

The backend driver reads a mode in which the receiving thread is in a polling mode when being allowed to read a mode in which the receiving thread is located; or

The backend driver, when being prohibited from reading the mode in which the receiving thread is located, waits for a predetermined time and then attempts to read the mode in which the receiving thread is located until it is allowed and reads the receiving thread. The mode is in polling mode.

The mode in which the receiving thread is located may be stored in a shared variable between the backend driver and the receiving thread. The backend driver attempts to read the receiving thread to the shared memory When the mode is enabled, the mode in which the receiving thread is located is read. If prohibited, the backend driver waits for a predetermined time and again attempts to read the mode in which the receiving thread is located to the shared memory until it is allowed and reads the mode in which the receiving thread is located.

Since the receiving thread can be used by multiple backend drivers. Therefore, when the other backend driver is in the mode modification of the receiving thread, the backend driver is prohibited from reading the mode in which the receiving thread is located, and therefore, the backend driver can be guaranteed not to read. A processing error occurred while fetching the error mode of the receiving thread.

In one of the possible designs, after determining that the mode in which the receiving thread of the Dom0 is in the polling mode, the backend driver further includes:

When it is determined that the remaining memory space in the skb queue is not less than the second space threshold and determines that the time when the receiving thread is in the polling mode reaches a time threshold, the mode in which the receiving thread is located is modified from the polling mode to In the non-polling mode, the non-polling mode is used to identify that the receiving thread is in the skb queue is empty or when the shared memory between the front end driver of the user virtual machine DomU and the backend driver is full Sleep state.

In the above design, after determining that the remaining memory space in the skb queue is not less than the second space threshold and determining that the receiving thread is in the polling mode, the time threshold is reached, that is, the skb queue receives the thread processing during this time. The number of data packets is small, so the mode in which the receiving thread is located can be modified from the polling mode to the non-polling mode, that is, the receiving thread is allowed to sleep when the skb queue is empty, thereby enabling the receiving thread to It will not waste resources when it is not working for a long time.

In one possible design, the method may further include: the back end driving the second data packet sent by the event channel of the receiving VMM; the back end driving processing the received second data packet After being stored in the skb queue, when it is determined that the remaining memory space in the skb queue is smaller than the first space threshold and it is determined that the mode in which the receiving thread is in the non-polling mode, the mode in which the receiving thread is located is not round The polling mode is modified to a polling mode, and the non-polling mode is used to identify that the receiving thread is empty in the skb queue or the shared memory between the front end driver of the user virtual machine DomU and the backend driver is full. While in a sleep state; the backend driver wakes up the receiving thread.

In the above design, determining that the remaining memory space in the skb queue is smaller than the second space threshold and determining The receiving thread is in the non-polling mode, that is, the number of data packets processed by the receiving thread in the skb queue is large during the period, and the mode in which the receiving thread is located is modified from the non-polling mode to the The polling mode, that is, forcing the dormant when the receiving thread is in the polling mode, causes the backend driver to no longer need to wake up the receiving thread when it knows that the receiving thread is in the polling mode, improving the performance of the backend.

In one possible design, the backend driver sets a write lock on a mode in which the receiving thread is located when modifying a mode in which the receiving thread is located, the write lock is used to prohibit other backends. Driving and the receiving thread reading a mode in which the receiving thread is located, and

After the mode modification of the receiving thread is completed, the write lock is released.

Since the receiving thread can be used by multiple backend drivers. Therefore, when the backend driver of the other privileged virtual machine modifies the mode in which the receiving thread is located, a write lock may be set to a mode in which the receiving thread is located, and the write lock is used to prohibit the Other backend drivers other than the backend driver that modify the mode of the receiving thread and the receiving thread read the mode in which the receiving thread is located. Then, after the mode modification of the receiving thread is completed, the write lock is released. By setting the write lock, it can be ensured that when the mode of the receiving thread is modified, other backend drivers and the receiving thread will not read the wrong mode and an error occurs.

In a second aspect, the embodiment of the present invention further provides a data processing method in a virtualization platform, where the method includes:

When the receiving thread of the Dom0 attempts to process the data packet in the skb queue, it is determined that the skb queue is empty or it is determined that the shared memory between the front end driver of the DomU and the back end driver of the Dom0 is full, and the receiving thread is read. Mode to be in;

The receiving thread does not need to sleep when reading the mode to the polling mode; the polling mode is used to identify that the receiving thread is in a non-sleep state.

In the prior art, it is determined that the skb queue is empty or that the shared memory between the front-end driver of the DomU and the back-end driver of the Dom0 is full, and the receiving thread must be dormant. In the solution provided by the embodiment of the present invention, the receiving thread is When the mode is determined to be polling mode, it will not go to sleep, that is, when the receiving thread is in polling mode, it will not sleep under any circumstances. Ensure that the back-end driver and front-end driver do not wake up the receiving thread in the polling mode, improving the receiving performance of the front and rear drivers.

In one of the possible designs, after the receiving thread reads the mode as the polling mode, the receiving thread further includes:

When the receiving thread determines that the mode in which the receiving thread that was last read needs to be in the non-polling mode, the receiving thread sends a mode for notifying the receiving thread to the front end driver of the user virtual machine DomU. The polling mode is changed to the notification information of the polling mode;

The non-polling mode is used to identify that the receiving thread is in a dormant state when the skb queue is empty or when the shared memory between the front end driver of the user virtual machine DomU and the backend driver is full.

In the prior art, the front-end driver attempts to wake up the receiving thread after generating a data request and placing it in the shared memory between the front-end driver and the back-end driver. In the embodiment of the present invention, when the receiving thread determines that the mode in which it is located changes, the front end has been notified that the receiving thread is changed from the non-polling mode to the polling mode. Therefore, the front-end driver can The mode of the receiving thread is stored. Therefore, after the front-end driver generates the first data request and places the shared memory between the front-end driver and the back-end driver, reading the mode of the receiving thread stored by itself, determining that the mode of reading the receiving thread is a round In the inquiry mode, it is not necessary to send a wake-up request to the receiving thread of the Dom0, which improves the receiving performance of the front-end driver.

In one of the possible designs, when the receiving thread reads the mode that the receiving thread needs to be in, it can be implemented as follows:

The receiving thread reads a mode in which the receiving thread needs to be in a mode that is allowed to read the receiving thread, or

When the receiving thread is prohibited from reading the mode that the receiving thread needs to be in, after waiting for a predetermined time, it tries again to read the mode that the receiving thread needs to be in, until it is allowed to read the receiving thread. mode.

In the above manner, it is possible to avoid the mode in which the receiving thread reads the error.

In one of the possible designs, the receiving thread determines that the skb queue is empty or determines that the shared memory between the front end driver of the user virtual machine DomU and the back end driver of the privileged virtual machine Dom0 is full, the method It can also include:

The receiving thread reads that the receiving thread needs to be in a non-polling mode and determines that the last read is When the mode in which the receiving thread needs to be in the polling mode, the notification information for notifying that the mode of the receiving thread is changed from the polling mode to the non-polling mode is sent to the front end driver.

The receiving thread needs to be in the non-polling mode when reading the receiving thread and the mode in which the receiving thread is last read to be in the polling mode, that is, the receiving thread sleeps when the condition is met, so The notification is modified to the front-end driver so that the front-end driver can wake up the receiving thread when it knows that the receiving thread is in the non-polling mode.

In a third aspect, an embodiment of the present invention provides a data processing method in a virtualization platform, where the method includes:

The front end driver of the DomU generates a first data request to be placed in the shared memory between the front end driver and the back end driver of Dom0;

When the front-end driver determines that the mode in which the receiving thread of Dom0 is in the polling mode, it is not necessary to send a wake-up request to the receiving thread of the Dom0, and the polling mode is used to identify that the receiving thread is in a non-sleep state.

In the above manner, when the front-end driver determines that the mode in which the receiving thread is in the polling mode, it is not necessary to send a wake-up request to the receiving thread of the Dom0, so that the front-end receiving performance caused by the frequent exit of the domU can be avoided.

In one of the possible designs, the method may further include:

The front end driver generates a second data request to be placed in the shared memory between the front end driver and the back end driver of the Dom0;

When the front-end driver receives the notification information sent by the receiving thread for notifying that the mode of the receiving thread is changed from the polling mode to the non-polling mode, the front-end driver sends the receiving thread to the receiving thread for awakening. The waking request of the receiving thread, the non-polling mode is used to identify that the receiving thread is in a sleep state when the skb queue is empty or when the shared memory between the front end driver of the DomU and the backend driver is full .

When the front-end driver receives the notification information sent by the receiving thread to notify the receiving thread that the mode is changed from the polling mode to the non-polling mode, it is determined that the mode of the receiving thread is changed from the polling mode to the non-round mode. Inquiry mode, that is, the receiving thread is in the non-polling mode at the moment, so it cannot be determined whether the receiving thread is sleeping at the moment, and the front-end driver needs to send the receiving thread to wake up. The receiving thread wakes up the request.

In a fourth aspect, the embodiment of the present invention further provides a data processing device in a virtualization platform, where the data processing device is applied to a backend driver of the Dom0, including:

a receiving unit, configured to receive a first data packet sent by an event channel of the VMM;

a processing unit, configured to: after the first data packet received by the receiving unit is processed and stored in a skb queue, when determining that a mode in which the receiving thread of the Dom0 is in a polling mode, Thread, the polling mode is used to identify that the receiving thread is in a non-sleep state.

In a possible design, the processing unit determines that the mode in which the receiving thread is located is a polling mode specifically for:

The backend driver reads a mode in which the receiving thread is in a polling mode when being allowed to read a mode in which the receiving thread is located.

In one of the possible designs, the processing unit is specifically configured to: when determining that the mode in which the receiving thread is in the polling mode:

When it is forbidden to read the mode in which the receiving thread is located, after waiting for a predetermined time, try again to read the mode in which the receiving thread is located until it is allowed and the mode in which the receiving thread is read is Polling mode.

In one of the possible designs, after determining that the mode in which the receiving thread of the Dom0 is in the polling mode, the processing unit is further configured to:

When it is determined that the remaining memory space in the skb queue is not less than the second space threshold and determines that the time when the receiving thread is in the polling mode reaches a time threshold, the mode in which the receiving thread is located is modified from the polling mode to In the non-polling mode, the non-polling mode is used to identify that the receiving thread is in a dormant state when the skb queue is empty or when the shared memory between the front end driver of the DomU and the backend driver is full.

In one possible design, the receiving unit is further configured to receive a second data packet sent by an event channel of the VMM;

The processing unit is further configured to: after the second data packet received by the receiving unit is processed and stored in the skb queue, determine that a remaining memory space in the skb queue is smaller than a first space threshold and Determining, when the mode in which the receiving thread is in the non-polling mode, modifying a mode in which the receiving thread is located from a non-polling mode to a polling mode, where the non-polling mode is used to identify that the receiving thread is The skb queue is empty or is in a sleep state when the shared memory between the front end driver of the DomU and the backend driver is full; the receiving thread is woken up.

In one possible design, the processing unit is further configured to set a write lock on a mode in which the receiving thread is located when modifying a mode in which the receiving thread is located, where the write lock is used to prohibit Other backend drivers and the receiving thread read the mode in which the receiving thread is located, and

After the mode modification of the receiving thread is completed, the write lock is released.

In a fifth aspect, the embodiment of the present invention further provides a data processing device in a virtualization platform, where the data processing device is applied to a receiving thread of the Dom0, including:

a determining unit, configured to determine whether the skb queue is empty or to determine whether the shared memory between the front end driver of the DomU and the back end driver of the Dom0 is full when attempting to process the data packet in the skb queue;

The reading unit reads a mode that the receiving thread needs to be in when determining that the skb queue is empty or determines that the shared memory between the front end driver of the DomU and the back end driver of the Dom0 is full; and is reading When the mode is the polling mode, the receiving thread does not need to sleep; the polling mode is used to identify that the receiving thread is in a non-sleep state.

In a possible design, the determining unit is further configured to: after the reading unit reads that the mode is a polling mode, determine a mode that the receiving thread that is last read needs to be in ;

Also includes:

The first notification unit, when determining that the last read mode of the receiving thread needs to be in the non-polling mode, sending a mode for notifying the receiving thread to the front end driver of the DomU to change from the non-polling mode to Notification information for polling mode;

The non-polling mode is configured to identify that the receiving thread is in a sleep state when the skb queue is empty or when the shared memory between the front end driver of the DomU and the backend driver is full.

In one possible design, the reading unit reads a mode in which the receiving thread needs to be in, specifically for reading the receiving when it is allowed to read a mode in which the receiving thread needs to be in Line The mode that the process needs to be.

In one of the possible designs, the reading unit is in a mode in which the receiving thread needs to be read, specifically for:

When it is forbidden to read the mode that the receiving thread needs to be in, after waiting for a predetermined time, try again to read the mode that the receiving thread needs to be in until the mode in which the receiving thread needs to be read is allowed to be read.

Among one of the possible designs, it also includes:

a second notification unit, configured to: after the determining unit determines that the skb queue is empty or determines that the shared memory between the front end driver of the DomU and the back end driver of the Dom0 is full, the reading unit reads the The receiving thread needs to be in the non-polling mode and the determining unit determines that the mode in which the receiving thread needs to be in the polling mode last time is sent to the front end driver to send a mode for notifying the receiving thread The polling mode is changed to the notification information of the non-polling mode.

In a sixth aspect, the embodiment of the present invention further provides a data processing device in a virtualization platform, where the data processing device is applied to a front end driver of the DomU, including:

a processing unit, configured to generate a first data request and place a shared memory between the front end driver and a backend driver of the privileged virtual machine Dom0;

a sending unit, configured to: when the processing unit determines that a mode in which the receiving thread of the Dom0 is in a polling mode, does not need to send a wakeup request to the receiving thread of the Dom0, where the polling mode is used to identify that the receiving thread is in a non-sleeping state. status.

In one possible design, the processing unit is further configured to generate a second data request to be placed in a shared memory between the front end driver and the back end driver;

Also includes:

a receiving unit, configured to receive, by the receiving thread, notification information for notifying that the mode of the receiving thread is changed from a polling mode to a non-polling mode;

The sending unit is further configured to: when the receiving unit receives the notification information, send a wakeup request for waking up the receiving thread to the receiving thread, where the non-polling mode is used to identify the receiving The thread is empty in the skb queue or is between the front end of the DomU and the backend driver When the memory is full, it is in a sleep state.

The backend driver of the Dom0 receives the first data packet sent by the event channel of the VMM. In the prior art, the backend driver does not know whether the receiving thread is dormant, so the backend driver processes the received first data packet. Storing in the network socket packet cache skb queue, the receiving thread needs to be awake, but with the solution provided by the embodiment of the present invention, the backend driver determines that the mode of the receiving thread of the Dom0 is in the polling mode. It is determined that the receiving thread is currently in a non-sleep state, so there is no need to wake up the receiving thread, and the polling mode is used to identify that the receiving thread is in a non-sleep state, thereby avoiding that the backend driver frequently wakes up the receiving thread.

After the front end driver of the DomU generates the first data request and is placed in the shared memory between the front end driver and the back end driver of the Dom0, the front end driver of the DomU in the prior art does not know whether the receiving thread is hibernating at the moment, and therefore needs to wake up the receiving thread. When the mode in which the receiving thread of the Dom0 is in the polling mode is determined by using the solution provided by the embodiment of the present invention, it is determined that the receiving thread is in the non-sleep state at the moment, so there is no need to send a wakeup request to the receiving thread of the Dom0, thereby avoiding DomU has frequent exits.

DRAWINGS

FIG. 1 is a schematic diagram of a virtualization platform according to an embodiment of the present invention;

2 is a schematic diagram of a process for implementing data processing of a device in a virtualization platform according to an embodiment of the present invention;

3 is a flowchart of data processing performed by a netback according to an embodiment of the present invention;

4 is a flowchart of data processing performed by a receiving thread according to an embodiment of the present invention;

FIG. 5 is a flowchart of data processing performed by the netfront according to an embodiment of the present invention;

FIG. 6 is a schematic diagram of a data processing apparatus applied to a backend driving according to an embodiment of the present invention;

FIG. 7 is a schematic diagram of another data processing apparatus applied to a backend driving according to an embodiment of the present invention;

FIG. 8 is a schematic diagram of a data processing apparatus applied to a receiving thread according to an embodiment of the present invention;

FIG. 9 is a schematic diagram of another data processing apparatus applied to a receiving thread according to an embodiment of the present invention;

FIG. 10 is a schematic diagram of a data processing apparatus applied to front end driving according to an embodiment of the present invention; FIG.

FIG. 11 is a schematic diagram of another data processing apparatus applied to front end driving according to an embodiment of the present invention.

detailed description

The present invention will be further described in detail with reference to the accompanying drawings, in which FIG. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.

The embodiment of the invention provides a data processing method and device in a virtualization platform, which is used to solve the problem that the back-end driver frequently wakes up the receiving thread and the DomU frequently exits in the prior art, thereby causing low performance of the existing network front and back end under XEN. The problem. The method and the device are based on the same inventive concept. Since the principles of the method and the device for solving the problem are similar, the implementation of the device and the method can be referred to each other, and the repeated description is not repeated.

The embodiment of the present invention is applied to a virtualization platform. As shown in FIG. 1 , the virtualization platform includes a virtual machine monitor (English: Virtual Machine Monitor, VMM for short) and a privileged virtual machine (Domain 0, referred to as Dom0). ) and multiple guest virtual machines (Domain U, referred to as DomU).

The VMM runs between the guest virtual machine and the hardware, and both Dom0 and DomU run on top of the VMM layer. The VMM is used to manage physical network cards (NICs), and packets destined for DomU first arrive at the NIC.

The special feature of Dom0 is that it has management tools for managing other DomUs and interfaces with VMMs to control the virtual environment. The Dom0 side also includes an interface for receiving DomU hardware access information, called a backend driver (netback), and the backend driver can receive hardware requests from all DomUs on the same physical machine. The DomU side also includes an interface to send hardware requests to Dom0, called front-end driver (netfront).

There is a fixed shared memory between Dom0 and DomU, that is, an input/output port (English: input/output, referred to as I/O) ring, which is used to transfer data requests and data responses between DomU and Dom0. Dom0 and DomU exchange data requests and data responses with each other through the settings on the VMM. The event channel, that is, Dom0 and DomU exchange data requests and data responses with each other through Dom0<->VMM<->DomU.

Based on the virtualization platform shown in Figure 1, the flow of data processing implemented by devices in the virtualization platform is shown in Figure 2.

FIG. 3 is a flowchart of a method for processing data applied to the virtualization platform according to an embodiment of the present invention.

DomU's netfront pre-applies for memory space. This memory space is used to store packets destined for the DomU. For this memory space, where DomU can be accessed, and Dom0 can also be accessed.

DomU's netfront carries the memory address of the requested memory space in the data request (req) and places it on the I/O ring. For example, req1 to req6 shown in the solid line I/O ring in FIG.

The VMM determines that the NIC receives the first data packet destined for the DomU. The VMM sends the first data packet to the netback of Dom0 through the event channel.

The event channel includes between Dom0 and VMM and between DomU and VMM. Specifically, the VMM sends the first data packet to the netback of the Dom0 through an event channel between the Dom0 and the VMM.

The following describes the processing flow of netback in detail, as shown in Figure 3.

S301. After receiving the first data packet sent by the VMM, the netback of the Dom0 processes the first data packet and stores the first data packet in the skb queue. In the embodiment of the present invention, the skb queue is taken as an example of skb_list, as shown in FIG. 2 .

Specifically, the netback of the Dom0 encapsulates the first data packet, specifically encapsulated into a skb format, and then placed in the skb_list.

S302. The netback determines that the mode in which the receiving thread of the Dom0 is located is a polling mode, and does not need to wake up the receiving thread.

The mode in which the receiving thread is located includes a polling mode and a non-polling mode. The polling mode is used to identify that the receiving thread is in non-sleep mode. The non-polling mode is used to identify that the receiving thread is in a sleep state when the skb queue is empty or when an I/O ring shared between the netfront of the DomU and the netback is full.

In the prior art, netback does not know whether the receiving thread is dormant, so the netback will be connected. After the received first data packet is processed and stored in the skb queue, the receiving thread needs to be awake, but with the solution provided by the embodiment of the present invention, the netback determines that the mode of the receiving thread of the Dom0 is polling. In the mode, it is determined that the receiving thread is currently in a non-sleep state, so there is no need to wake up the receiving thread, thereby avoiding netback frequently waking up the receiving thread.

Among them, you can set the receiving thread to be in polling mode. The mode in which the receiving thread is located is always in polling mode and does not change to non-polling mode, which ensures that the receiving thread will not sleep. But this way the receiving thread is always working, which will result in wasted resources. Therefore, it can be set that the mode in which the receiving thread is located can become a non-polling mode under certain conditions.

Therefore, optionally, after the netback determines that the mode in which the receiving thread of the Dom0 is in the polling mode, the method may further include:

When the netback determines that the remaining memory space in the skb queue is not less than the second space threshold and determines that the time when the receiving thread is in the polling mode reaches a time threshold, the mode in which the receiving thread is located is modified from the polling mode to The non-polling mode.

After determining that the remaining memory space in the skb queue is not less than the second space threshold and determining that the receiving thread is in the polling mode, the time threshold is reached, that is, the number of data packets processed by the receiving thread in the skb queue is shorter. Small, so the mode in which the receiving thread is located can be modified from the polling mode to the non-polling mode, that is, the receiving thread is allowed to sleep when the skb queue is empty, so that the receiving thread will not be in the long-term Work status and waste resources.

Then, since the receiving thread is in the non-polling mode, that is, the state in which the receiving thread is in the prior art, the receiving thread determines whether the remaining memory space in the skb queue is empty or is shared between the netfront of the DomU and the netback. When the I/O ring is full, it sleeps, so it can make the receiving thread sleep when there is no data to process, or when the processed data cannot be placed in the I/O ring to make the netfront processing, so that the receiving thread can be avoided. It has been working, and the resources caused are wasted.

The netback determines that the mode in which the receiving thread of the Dom0 is located is a polling mode, and specifically includes:

Reading the receiving line when the netback is allowed to read the mode in which the receiving thread is located The mode in which the process is located is the polling mode; or,

The netback, after being prohibited from reading the mode in which the receiving thread is located, waits for a predetermined time and then attempts to read the mode in which the receiving thread is located until it is allowed and reads the receiving thread. The mode is polling mode.

Since the receiving thread can be used by multiple netbacks. Therefore, when other netbacks modify the mode of the receiving thread, the netback is prohibited from reading the mode in which the receiving thread is located, and therefore, the netback can be guaranteed not to read the error of the receiving thread. A processing error occurred in the mode. In addition, when the netback of the other privileged virtual machine modifies the mode in which the receiving thread is located, a write lock may be set to a mode in which the receiving thread is located, and the write lock is used to prohibit the The netback other than the netback that receives the modified mode of the thread and the receiving thread read the mode in which the receiving thread is located. Then, after the mode modification of the receiving thread is completed, the write lock is released, so when the netback is prohibited from reading the mode in which the receiving thread is located, after waiting for a predetermined time, the netback may be tried again. Take the mode in which the receiving thread is located.

By setting the write lock, it can be ensured that when the mode of the receiving thread is modified, other netbacks and the receiving thread will not read the wrong mode and an error occurs.

The netback and the receiving thread are two threads belonging to the same virtual machine operating system, and the receiving thread mode can be stored in a shared variable that both threads can read. Therefore, when netback modifies the mode of the receiving thread stored in the shared variable, a write lock is set to the mode of the receiving thread in the shared variable.

Optionally, the method may further include: the netback receives the second data packet sent by the event channel of the VMM; the netback processes the received second data packet after being processed in the skb queue, and determines When the remaining memory space in the skb queue is smaller than the first space threshold and determining that the mode in which the receiving thread is in the non-polling mode, the mode in which the receiving thread is located is changed from the non-polling mode to the polling mode. The non-polling mode is configured to identify that the receiving thread is in a sleep state when the skb queue is empty or when the shared memory between the netfront and the netback is full; the netback wakes up the receiving thread.

In the above design, determining that the remaining memory space in the skb queue is smaller than the second space threshold and determining The receiving thread is in the non-polling mode, that is, the number of data packets processed by the receiving thread in the skb queue is large during the period, and the mode in which the receiving thread is located is modified from the non-polling mode to the The polling mode, that is, forcing to do not sleep when the receiving thread is in the polling mode, causes the netback to no longer need to wake up the receiving thread when it knows that the receiving thread is in the polling mode, thereby improving the performance of the back end.

After the netback performs the above processing, the receiving thread performs the following processing, as shown in FIG.

S401. When the receiving thread of Dom0 attempts to process the data packet in the skb queue, determine that the skb queue is empty or determine that the I/O ring between the netfront of the DomU and the netback of the Dom0 is full, and read the receiving. The mode in which the thread needs to be.

First, when netback changes the mode of the receiving thread, you can set the write lock without setting the write lock. When the write lock is not set, the receiving thread does not need to determine whether it is allowed to read the mode in which the receiving thread needs to be in reading the mode that it is in. If the write lock is set, the receiving thread can realize the mode in which the receiving thread needs to be in the following manner:

The receiving thread reads a mode in which the receiving thread needs to be in a mode that is allowed to read the receiving thread; or

When the receiving thread is prohibited from reading the mode that the receiving thread needs to be in, after waiting for a predetermined time, it tries again to read the mode that the receiving thread needs to be in, until it is allowed to read the receiving thread. mode.

S402. The receiving thread does not need to sleep when reading the mode to the polling mode.

The polling mode is used to identify that the receiving thread is in a non-sleep state.

In the prior art, it is determined that the skb queue is empty or that the shared memory between the netfront of the user virtual machine DomU and the netback of the privileged virtual machine Dom0 is full, and the receiving thread must be dormant. In the solution provided by the embodiment of the present invention, When the receiving thread determines that the mode is polling mode, it does not go to sleep, that is, when the receiving thread is in polling mode, it will not sleep under any circumstances. Ensure that netback and netfront do not wake up the receiving thread when in polling mode, improving the receiving performance of the former netback.

If the receiving thread does not sleep after the skb queue is empty, the receiving thread can wait and try to process the data packets in the skb queue at regular intervals.

Wherein, the skb is not empty and the netfront of the DomU is determined with the netback of the Dom0 If the I/O ring is not full, the receiving thread will definitely not sleep. The receiving thread processes the data packet in the skb queue, reads a data packet, and copies the data included in the data packet to the memory space corresponding to the memory address carried by the data request (req) on the I/O ring, and then The memory address corresponding to the copied data carries the location occupied by the data request (req) before being placed on the IO ring in the data response, and sends a notification message through the event channel to notify the DomU that the data needs to be processed. Thus netfront reads the I/O ring and processes the data stored in the memory address carried in the data response.

For example, here, taking the data response as rep1 as an example, replacing rsq1 shown in the solid line I/O ring of FIG. 2 with rep1 placed in the dotted I/O ring.

Specifically, the receiving thread in S401 may try to process the data packet in the skb queue. Then first determine if the skb queue is empty or determine if the I/O ring between the netfront of the DomU and the netback of the Dom0 is full.

If it is determined that the skb queue is empty or it is determined that the shared I/O ring between the netfront of the DomU and the netback of the Dom0 is full, reading a mode in which the receiving thread needs to be in, the receiving thread reads the When the mode is polling mode, no hibernation is required. Since the receiving thread attempts to process the data packet in the skb queue, the receiving thread is definitely in a non-sleep state at this moment, so there is no need to sleep, that is, the receiving thread remains in a non-sleep state.

Optionally, when the receiving thread determines that the mode that the receiving thread that was last read needs to be in a non-polling mode, the receiving thread sends a mode for notifying the receiving thread to the netfront of the DomU. The polling mode is changed to the notification information of the polling mode.

In the prior art, netfront attempts to wake up the receiving thread after generating a data request and placing it in shared memory between netfront and netback. In the embodiment of the present invention, the receiving thread has notified the netfront that the receiving thread is changed from the non-polling mode to the polling mode due to the receiving thread, so that the netfront can receive the receiving. The mode of the thread is stored. Therefore, after the netfront generates the first data request and is placed in the shared memory between the netfront and the netback, reading the mode of the receiving thread stored by itself, when determining that the mode of reading the receiving thread is the polling mode, There is no need to send a wakeup request to the receiving thread of the Dom0, High before the netback reception performance.

Optionally, after the receiving thread determines that the skb queue is empty or determines that the I/O ring between the netfront of the DomU and the netback of the Dom0 is full, the receiving thread reads that the receiving thread needs to be in a non-round Query mode and determine that the mode in which the receiving thread is in the polling mode last time is sent to the netfront to send notification information indicating that the mode of the receiving thread is changed from the polling mode to the non-polling mode. .

The receiving thread needs to be in the non-polling mode when reading the receiving thread and the mode in which the receiving thread is last read to be in the polling mode, that is, the receiving thread sleeps when the condition is met, so Modify the notification to netfront so that netfront can wake up the receiving thread when it knows that the receiving thread is in non-polling mode.

Here, the receiving thread reads the mode that the receiving thread needs to be in, and can read from the shared variable between the receiving thread and the netback.

The mode of storing the receiving thread between the netfront and the receiving thread can be implemented by Xenstore, which is a tree database located in Dom0, and stores configuration information of all running DomUs. So you can set a fixed key value in Xenstore to correspond to the mode in which the receiving thread should be. When the receiving thread reads from the shared variable between the receiving thread and the netback that the mode in which the receiving thread needs to be changed, the key value of the receiving thread is modified in Xenstore.

At the same time, Xenstore provides a "watch" listening mechanism, that is, when the receiving thread modifies the key value of the mode of the receiving thread in Xenstore, Xenstore is triggered to send notification information to the netfront, the notification information is used to notify the receiving thread The pattern at the place has changed. Specifically, the netfront said receiving thread changes from a non-polling mode to a polling mode, or a polling mode to a non-polling mode.

When the receiving thread sends a notification message through the event channel to notify the DomU that the data needs to be processed, the netfront reads the I/O ring and processes the data stored in the memory address carried in the data response. After netfront processes a data response, it will apply for memory space again, and carry the memory address of the requested memory space in the data request (req) and place it on the I/O ring.

Specifically, the netfront of DomU is processed as follows, as shown in FIG. 5.

S501. The netfront of the DomU generates a first data request to place an I/O ring between the netfront and the netback of the Dom0.

S502. The netfront of the DomU determines that the mode in which the receiving thread of the Dom0 is in the polling mode, and does not need to send a wake-up request to the receiving thread of the Dom0.

The polling mode is used to identify that the receiving thread is in a non-sleep state.

Due to the receiving thread, when it is determined that the mode in which it is located has changed, it has been notified to the netfront whether the receiving thread has changed from the non-polling mode to the polling mode or the polling mode has changed to the non-polling mode. Therefore, netfront can store the mode of the receiving thread. Therefore, after the netfront generates the first data request and places the I/O ring between the netfront and the netback, reading the mode of the receiving thread stored by itself, determining that the mode of reading the receiving thread is the polling mode At this time, it is not necessary to send a wake-up request to the receiving thread of the Dom0, so that the front-end receiving performance caused by the frequent exit of the domU can be avoided.

Optionally, after the netfront generates a second data request and is placed in an I/O ring between the netfront and the netback of the Dom0, the netfront receives a mode sent by the receiving thread to notify the receiving thread. When the polling mode is changed to the notification information of the non-polling mode, the netfront sends a wakeup request for waking up the receiving thread to the receiving thread.

When the netfront receives the notification information sent by the receiving thread to notify the receiving thread that the mode is changed from the polling mode to the non-polling mode, it is determined that the mode of the receiving thread is changed from the polling mode to the non-polling mode. The mode, that is, the receiving thread is now in the non-polling mode, and therefore cannot determine whether the receiving thread is hibernating at the moment, and the netfront needs to send a wake-up request for waking up the receiving thread to the receiving thread.

The netback of the Dom0 receives the first data packet sent by the event channel of the virtual machine monitor VMM. In the prior art, the netback does not know whether the receiving thread is dormant, so the netback processes the received first data packet and stores it in the In the skb queue of the network socket cache, the receiving thread needs to be awake, but with the solution provided by the embodiment of the present invention, the netback determines the receiving when determining that the mode of the receiving thread of the Dom0 is in the polling mode. The thread is currently in a non-sleep state, so there is no need The receiving thread is woken up, and the polling mode is used to identify that the receiving thread is in a non-sleep state, thereby preventing the netback from frequently waking up the receiving thread.

After the first data request of the DomU's netfront is placed in the I/O ring between the netfront and the netback of the Dom0, the netfront of the DomU in the prior art does not know whether the receiving thread is hibernating at the moment, and therefore needs to wake up the receiving thread, and utilize the present The solution provided by the embodiment of the present invention determines that the mode in which the receiving thread of the Dom0 is in the polling mode determines that the receiving thread is in the non-sleep state at the moment, and therefore does not need to send a wakeup request to the receiving thread of the Dom0, thereby avoiding frequent DomU. Exit.

Based on the same inventive concept as the method embodiment corresponding to FIG. 3, the embodiment of the present invention further provides a data processing apparatus in a virtualization platform. As shown in FIG. 6, the data processing apparatus is applied to a privileged virtual machine Dom0. Backend drive, the device includes:

The receiving unit 601 is configured to receive a first data packet sent by an event channel of the VMM.

The processing unit 602 is configured to: after the first data packet received by the receiving unit 601 is processed and stored in the skb queue, when determining that the mode of the receiving thread of the Dom0 is in a polling mode, The receiving thread is configured to identify that the receiving thread is in a non-sleep state.

Optionally, the processing unit 602, in determining that the mode in which the receiving thread is located, is a polling mode, which may be implemented by:

The first way to achieve:

When the mode in which the receiving thread is allowed to be read is read, the mode in which the receiving thread is located is read as a polling mode.

The second way to achieve:

When it is forbidden to read the mode in which the receiving thread is located, after waiting for a predetermined time, try again to read the mode in which the receiving thread is located until it is allowed and the mode in which the receiving thread is read is Polling mode.

Optionally, after determining that the mode in which the receiving thread of the Dom0 is in the polling mode, the processing unit 602 is further configured to:

When determining that the remaining memory space in the skb queue is not less than the second space threshold and determining that the time when the receiving thread is in the polling mode reaches a time threshold, the mode in which the receiving thread is located is by the round The mode is modified to the non-polling mode, and the non-polling mode is used to identify that the receiving thread is empty in the skb queue or is shared between the front end driver of the user virtual machine DomU and the backend driver. When the memory is full, it is in a sleep state.

Optionally, the receiving unit 601 is further configured to receive a second data packet sent by an event channel of the VMM.

The processing unit 602 is further configured to: after the second data packet received by the receiving unit 601 is processed and stored in the skb queue, determine that the remaining memory space in the skb queue is smaller than the first space threshold and determine the location When the mode in which the receiving thread is in the non-polling mode, the mode in which the receiving thread is located is modified from a non-polling mode to a polling mode, and the non-polling mode is used to identify the receiving thread in the The skb queue is empty or is in a sleep state when the shared memory between the front end driver of the user virtual machine DomU and the backend driver is full; the receiving thread is woken up.

Optionally, the processing unit 602 is further configured to: when the mode of the receiving thread is modified, set a write lock on a mode in which the receiving thread is located, where the write lock is used to prohibit other backend drivers. And the receiving thread reads the mode in which the receiving thread is located, and releases the write lock after the mode modification of the receiving thread is completed.

The division of the unit in the embodiment of the present invention is schematic, and is only a logical function division. In actual implementation, there may be another division manner. In addition, each functional unit in each embodiment of the present application may be integrated into one processing. In the device, it may be physically present alone, or two or more units may be integrated in one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software function module.

When the integrated unit is implemented in the form of hardware, as shown in FIG. 7 , the hardware of the entity corresponding to the receiving unit 601 is the communication interface 701 , and the physical hardware corresponding to the processing unit 602 is the processor 702 . The processor 702 can be a central processing unit (English: central processing unit, CPU for short), or a digital processing unit or the like.

The data processing apparatus further includes a memory 703 for storing a program executed by the processor 702. The processor 702 is configured to execute a program stored in the memory 703, specifically for the processing unit 602 and the scheme executed by the receiving unit 601. The memory 703 can also be used to store skb queues.

The specific connection medium between the communication interface 701, the processor 702, and the memory 703 is not limited in the embodiment of the present invention. In the embodiment of the present invention, the memory 703, the processor 702, and the communication interface 701 are connected by a bus 704 in FIG. 7. The bus is shown by a thick line in FIG. 7, and the connection manner between other components is only for illustrative description. , not limited to. The bus can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is shown in Figure 7, but it does not mean that there is only one bus or one type of bus.

The memory 703 may be a volatile memory (English: volatile memory), such as a random access memory (English: random-access memory, abbreviation: RAM); the memory may also be a non-volatile memory (English: non-volatile memory). For example, read-only memory (English: read-only memory, abbreviation: ROM), flash memory (English: flash memory), hard disk (English: hard disk drive, abbreviation: HDD) or solid state drive (English: solid-state drive, Abbreviations: SSD), or memory, are any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto. The memory can be a combination of the above memories.

Based on the same inventive concept as the method embodiment shown in FIG. 4, the embodiment of the present invention further provides a data processing apparatus in a virtualization platform, where the data processing apparatus is applied to a receiving thread of Dom0, as shown in FIG. The data processing device includes:

a determining unit 801, configured to determine whether the skb queue is empty or to determine whether the shared memory between the front end driver of the DomU and the backend driver of the Dom0 is full when attempting to process the data packet in the skb queue;

The reading unit 802, when determining that the skb queue is empty or determining that the shared memory between the front-end driver of the user virtual machine DomU and the back-end driver of the privileged virtual machine Dom0 is full, reading the receiving thread needs to be in And the receiving thread does not need to sleep when reading the mode to the polling mode; the polling mode is used to identify that the receiving thread is in a non-sleep state.

Optionally, the determining unit 801 is further configured to: after the reading unit 802 reads that the mode is a polling mode, determine a mode that the receiving thread that is last read needs to be in;

Also includes:

The first notification unit 803, when the determining unit 801 determines that the mode in which the receiving thread that was last read is to be in the non-polling mode, sends a mode for notifying the receiving thread to the front end driver of the user virtual machine DomU. Notification information changed from non-polling mode to polling mode.

The non-polling mode is used to identify that the receiving thread is in a dormant state when the skb queue is empty or when the shared memory between the front end driver of the DomU and the backend driver is full.

Optionally, the reading unit 802 is configured to read a mode that the receiving thread needs to be in, specifically for reading, when the mode that the receiving thread needs to be read is read, mode.

Optionally, the reading unit 802 is in a mode in which the receiving thread needs to be read, and is specifically configured to:

When it is forbidden to read the mode that the receiving thread needs to be in, after waiting for a predetermined time, try again to read the mode that the receiving thread needs to be in until the mode in which the receiving thread needs to be read is allowed to be read.

Optionally, the data processing apparatus may further include:

a second notification unit 804, configured to: after the determining unit 801 determines that the skb queue is empty or determines that the shared memory between the front end driver of the DomU and the back end driver of the Dom0 is full, the reading unit 802 reads When the receiving thread needs to be in the non-polling mode and the determining unit 801 determines that the mode that the receiving thread needs to be in the polling mode last time, the sending to the front end driver is sent to notify the receiving thread. The mode is changed from polling mode to notification information in non-polling mode.

The division of the unit in the embodiment of the present invention is schematic, and is only a logical function division. In actual implementation, there may be another division manner. In addition, each functional unit in each embodiment of the present application may be integrated into one processing. In the device, it may be physically present alone, or two or more units may be integrated in one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software function module.

When the integrated unit is implemented in the form of hardware, as shown in FIG. 9, the hardware of the entity corresponding to the first notification unit 803 and the second notification unit 804 is the communication interface 901, and the determining unit 801 and the reading unit 802 correspond to each other. The physical hardware is processor 902. The processor 902 can be a CPU. Or a digital processing unit or the like.

The data processing apparatus further includes a memory 903 for storing a program executed by the processor 902. The processor 902 is configured to execute a program stored in the memory 903.

The specific connection medium between the communication interface 901, the processor 902, and the memory 903 is not limited in the embodiment of the present invention. In the embodiment of the present invention, the memory 903, the processor 902, and the communication interface 901 are connected by a bus 904 in FIG. 9. The bus is indicated by a thick line in FIG. 9, and the connection manner between other components is only schematically illustrated. , not limited to. The bus can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is shown in Figure 9, but it does not mean that there is only one bus or one type of bus.

The memory 903 can be a volatile memory such as a RAM; the memory 903 can also be a non-volatile memory such as a ROM, flash memory, HDD or SSD, or the memory 903 can be used to carry or store a desired program in the form of an instruction or data structure. Code and any other medium that can be accessed by a computer, but is not limited thereto. The memory 903 may be a combination of the above memories.

Based on the same inventive concept as the method embodiment shown in FIG. 5, the embodiment of the present invention further provides a data processing device in a virtualization platform, where the data processing device is applied to a front end driver of the DomU, as shown in FIG. The data processing device includes:

The processing unit 1001 is configured to generate a first data request and place the shared memory between the front end driver and the back end driver of the privileged virtual machine Dom0;

The sending unit 1002 is configured to: when the processing unit 1001 determines that the mode in which the receiving thread of the privileged virtual machine Dom0 is in the polling mode, does not need to send a wakeup request to the receiving thread of the Dom0, where the polling mode is used to identify The receiving thread is in a non-sleep state.

Optionally, the processing unit 1001 is further configured to generate a second data request to be placed in the shared memory between the front end driver and the back end driver;

Also includes:

The receiving unit 1003 is configured to receive, by the receiving thread, notification information for notifying that the mode of the receiving thread is changed from a polling mode to a non-polling mode;

The sending unit 1002 is further configured to: when the receiving unit 1003 receives the notification information, Sending, to the receiving thread, a wakeup request for waking up the receiving thread, where the non-polling mode is used to identify that the receiving thread is empty in the skb queue or is driven on the front end of the user virtual machine DomU The shared memory between the end drives is in a sleep state when full.

The division of the unit in the embodiment of the present invention is schematic, and is only a logical function division. In actual implementation, there may be another division manner. In addition, each functional unit in each embodiment of the present application may be integrated into one processing. In the device, it may be physically present alone, or two or more units may be integrated in one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software function module.

When the integrated unit is implemented in the form of hardware, as shown in FIG. 11, the hardware of the entity corresponding to the receiving unit 1003 and the sending unit 1002 is the communication interface 1101, and the processing unit 1001 is the processor 1102. The processor 1102 can be a CPU, or a digital processing unit or the like.

The data processing apparatus further includes a memory 1103 for storing a program executed by the processor 1102. The processor 1102 is configured to execute a program stored in the memory 1103.

The specific connection medium between the communication interface 1101, the processor 1102, and the memory 1103 is not limited in the embodiment of the present invention. In the embodiment of the present invention, the memory 1103, the processor 1102, and the communication interface 1101 are connected by a bus 1104 in FIG. 11, and the bus is indicated by a thick line in FIG. 11, and the connection manner between other components is only schematically illustrated. , not limited to. The bus can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is shown in Figure 11, but it does not mean that there is only one bus or one type of bus.

The memory 1103 can be a volatile memory, such as a RAM; the memory 1103 can also be a non-volatile memory, such as a ROM, flash memory, HDD or SSD, or the memory 1103 can be used to carry or store a desired program in the form of an instruction or data structure. Code and any other medium that can be accessed by a computer, but is not limited thereto. The memory 1103 may be a combination of the above memories.

The processor 702, the processor 902, and the processor 1102 in the embodiment of the present invention may be the same processor or different processors. The memory 703, the memory 903, and the memory 1103 may be the same memory or different memories for storing the skb queue and the shared memory. Save as well as xenstore and so on.

The backend driver of the Dom0 receives the first data packet sent by the event channel of the VMM. In the prior art, the backend driver does not know whether the receiving thread is dormant, so the backend driver processes the received first data packet. Storing in the network socket packet cache skb queue, the receiving thread needs to be awake, but with the solution provided by the embodiment of the present invention, the backend driver determines that the mode of the receiving thread of the Dom0 is in the polling mode. It is determined that the receiving thread is currently in a non-sleep state, so there is no need to wake up the receiving thread, and the polling mode is used to identify that the receiving thread is in a non-sleep state, thereby avoiding that the backend driver frequently wakes up the receiving thread.

After the front end driver of the DomU generates the first data request and is placed in the shared memory between the front end driver and the back end driver of the Dom0, the front end driver of the DomU in the prior art does not know whether the receiving thread is hibernating at the moment, and therefore needs to wake up the receiving thread. When the mode in which the receiving thread of the Dom0 is in the polling mode is determined by using the solution provided by the embodiment of the present invention, it is determined that the receiving thread is in the non-sleep state at the moment, so there is no need to send a wakeup request to the receiving thread of the Dom0, thereby avoiding DomU has frequent exits.

Those skilled in the art will appreciate that embodiments of the present invention can be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.

The present invention has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (system), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine for the execution of instructions for execution by a processor of a computer or other programmable data processing device. Means for implementing the functions specified in one or more of the flow or in a block or blocks of the flow chart.

The computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that it is stored in the computer readable memory. The instructions produce an article of manufacture including an instruction device that implements the functions specified in one or more blocks of the flowchart or in a flow or block diagram of the flowchart.

These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device. The instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.

While the preferred embodiment of the invention has been described, it will be understood that Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and the modifications and

It is apparent that those skilled in the art can make various modifications and variations to the invention without departing from the spirit and scope of the invention. Thus, it is intended that the present invention cover the modifications and modifications of the invention

Claims (26)

1. A data processing method in a virtualization platform, comprising:

   The backend driver of the privileged virtual machine Dom0 receives the first data packet sent by the event channel of the virtual machine monitor VMM;

   The backend driver stores the received first data packet and stores it in the network socket packet cache skb queue, and does not need to wake up when determining that the mode of the Dom0 receiving thread is in the polling mode. The receiving thread is configured to identify that the receiving thread is in a non-sleep state.
2. The method of claim 1, wherein the backend driver determines that the mode in which the receiving thread is located is a polling mode, including:

   The backend driver reads a mode in which the receiving thread is in a polling mode when being allowed to read a mode in which the receiving thread is located.
3. The method of claim 1, wherein the backend driver determines that the mode in which the receiving thread is located is a polling mode, including:

   The backend driver, when being prohibited from reading the mode in which the receiving thread is located, waits for a predetermined time and then attempts to read the mode in which the receiving thread is located until it is allowed and reads the receiving thread. The mode is in polling mode.
4. The method according to any one of claims 1 to 3, wherein the backend driver further comprises: after determining that the mode in which the receiving thread of the Dom0 is in the polling mode, further comprising:

   When it is determined that the remaining memory space in the skb queue is not less than the second space threshold and determines that the time when the receiving thread is in the polling mode reaches a time threshold, the mode in which the receiving thread is located is modified from the polling mode to In the non-polling mode, the non-polling mode is used to identify that the receiving thread is in the skb queue is empty or when the shared memory between the front end driver of the user virtual machine DomU and the backend driver is full Sleep state.
5. The method of claim 1 further comprising:

   The back end driver receives a second data packet sent by an event channel of the VMM;

   After the backend driver processes the received second data packet and stores it in the skb queue, When it is determined that the remaining memory space in the skb queue is smaller than the first space threshold and determining that the mode in which the receiving thread is in the non-polling mode, the mode in which the receiving thread is located is changed from the non-polling mode to the polling mode. The non-polling mode is configured to identify that the receiving thread is in a dormant state when the skb queue is empty or when the shared memory between the front end driver of the user virtual machine DomU and the backend driver is full;

   The backend driver wakes up the receiving thread.
6. The method of claim 4 or 5, further comprising:

   The backend driver sets a write lock on a mode in which the receiving thread is located when modifying a mode in which the receiving thread is located, the write lock is used to prohibit other backend drivers and the receiving thread from reading State the mode in which the receiving thread is located, and

   After the mode modification of the receiving thread is completed, the write lock is released.
7. A data processing method in a virtualization platform, comprising:

   When the receiving thread of the privileged virtual machine Dom0 attempts to process the data packet in the skb queue of the network socket packet cache, it is determined that the skb queue is empty or the front end driver of the user virtual machine DomU and the back end driver of the privileged virtual machine Dom0 are determined. When the shared memory is full, the mode in which the receiving thread needs to be read is read;

   The receiving thread does not need to sleep when reading the mode to the polling mode; the polling mode is used to identify that the receiving thread is in a non-sleep state.
8. The method of claim 7, wherein the receiving thread, after reading the mode to the polling mode, further comprises:

   When the receiving thread determines that the mode in which the receiving thread that was last read needs to be in the non-polling mode, the receiving thread sends a mode for notifying the receiving thread to the front end driver of the user virtual machine DomU. The polling mode is changed to the notification information of the polling mode;

   The non-polling mode is used to identify that the receiving thread is in a dormant state when the skb queue is empty or when the shared memory between the front end driver of the user virtual machine DomU and the backend driver is full.
9. The method according to claim 7 or 8, wherein the receiving thread reads a mode that the receiving thread needs to be in, including:

   The receiving thread reads the receiving when it is allowed to read a mode in which the receiving thread needs to be in The mode in which the thread needs to be.
10. The method according to claim 7 or 8, wherein the receiving thread reads a mode that the receiving thread needs to be in, including:

    When the receiving thread is prohibited from reading the mode that the receiving thread needs to be in, after waiting for a predetermined time, it tries again to read the mode that the receiving thread needs to be in, until it is allowed to read the receiving thread. mode.
11. The method according to any one of claims 7 to 10, wherein the receiving thread determines that the skb queue is empty or determines between the front end driver of the user virtual machine DomU and the back end driver of the privileged virtual machine Dom0. After the shared memory is full, it also includes:

    The receiving thread reads, when the receiving thread needs to be in the non-polling mode, and determines that the mode that the receiving thread needs to be in the polling mode last time, sends the notification to the front end driver to notify the receiving The mode of the thread is changed from polling mode to notification information in non-polling mode.
12. A data processing method in a virtualization platform, comprising:

    The front end driver of the user virtual machine DomU generates a first data request to be placed in the shared memory between the front end driver and the back end driver of the privileged virtual machine Dom0;

    When the front-end driver of the user virtual machine DomU determines that the mode in which the receiving thread of the privileged virtual machine Dom0 is in the polling mode, there is no need to send a wake-up request to the receiving thread of the Dom0, and the polling mode is used to identify that the receiving thread is not sleeping. status.
13. The method of claim 12, further comprising:

    The front end driver generates a second data request to be placed in a shared memory between the front end driver and a back end drive of the privileged virtual machine Dom0;

    When the front-end driver receives the notification information sent by the receiving thread for notifying that the mode of the receiving thread is changed from the polling mode to the non-polling mode, the front-end driver sends the receiving thread to the receiving thread for awakening. The wake-up request of the receiving thread, the non-polling mode is used to identify that the receiving thread is empty when the skb queue is empty or when the shared memory between the front-end driver of the user virtual machine DomU and the backend driver is full Is in a dormant state.
14. A data processing device in a virtualization platform, characterized in that the data processing device The backend driver applied to the privileged virtual machine Dom0, including:

    a receiving unit, configured to receive a first data packet sent by an event channel of the virtual machine monitor VMM;

    a processing unit, configured to: after the first data packet received by the receiving unit is processed and stored in a network socket buffer skb queue, when determining that the mode of receiving the Dom0 is in a polling mode There is no need to wake up the receiving thread, and the polling mode is used to identify that the receiving thread is in a non-sleep state.
15. The apparatus according to claim 14, wherein the processing unit determines that the mode in which the receiving thread is located is a polling mode, specifically for:

    When the mode in which the receiving thread is allowed to be read is read, the mode in which the receiving thread is located is read as a polling mode.
16. The device according to claim 14, wherein the processing unit is configured to: when determining that the mode in which the receiving thread is in the polling mode:

    When it is forbidden to read the mode in which the receiving thread is located, after waiting for a predetermined time, try again to read the mode in which the receiving thread is located until it is allowed and the mode in which the receiving thread is read is Polling mode.
17. The device according to any one of claims 14 to 16, wherein the processing unit is further configured to: after determining that the mode in which the receiving thread of the Dom0 is in the polling mode:

    When it is determined that the remaining memory space in the skb queue is not less than the second space threshold and determines that the time when the receiving thread is in the polling mode reaches a time threshold, the mode in which the receiving thread is located is modified from the polling mode to In the non-polling mode, the non-polling mode is used to identify that the receiving thread is in the skb queue is empty or when the shared memory between the front end driver of the user virtual machine DomU and the backend driver is full Sleep state.
18. The apparatus according to claim 14, wherein the receiving unit is further configured to receive a second data packet sent by an event channel of the VMM;

    The processing unit is further configured to: after the second data packet received by the receiving unit is processed and stored in the skb queue, determine that the remaining memory space in the skb queue is smaller than the first space threshold and determine the receiving When the mode in which the thread is in the non-polling mode, the mode in which the receiving thread is located is The non-polling mode is modified to a polling mode, and the non-polling mode is used to identify that the receiving thread is empty in the skb queue or shared memory between the front end of the user virtual machine DomU and the backend driver. Is in a sleep state when full; wakes up the receiving thread.
19. The device according to claim 17 or 18, wherein the processing unit is further configured to set a write lock on a mode in which the receiving thread is located when modifying a mode in which the receiving thread is located. The write lock is used to disable other backend drivers and the receiving thread reads the mode in which the receiving thread is located, and

    After the mode modification of the receiving thread is completed, the write lock is released.
20. A data processing device in a virtualization platform, wherein the data processing device is applied to a receiving thread of the privileged virtual machine Dom0, including:

    a determining unit, configured to determine whether the skb queue is empty or to determine a front end driver of the user virtual machine DomU and a backend driver of the privileged virtual machine Dom0 when attempting to process a data packet in the network socket buffer skb queue Whether the shared memory between is full;

    The reading unit reads that the receiving thread needs to be in the process of determining that the skb queue is empty or determining that the shared memory between the front end driver of the user virtual machine DomU and the back end driver of the privileged virtual machine Dom0 is full. Mode; and when the mode is read to be polling mode, the receiving thread does not need to sleep; the polling mode is used to identify that the receiving thread is in a non-sleep state.
21. The device according to claim 20, wherein the determining unit is further configured to: after the reading unit reads that the mode is a polling mode, determine the receiving thread that was last read Mode to be in;

    Also includes:

    a first notification unit, configured to send a mode for notifying the receiving thread to the front end driver of the user virtual machine DomU when the mode in which the receiving thread is last read is in a non-polling mode, by the non-polling mode The mode is changed to the notification information of the polling mode;

    The non-polling mode is used to identify that the receiving thread is in a dormant state when the skb queue is empty or when the shared memory between the front end driver of the user virtual machine DomU and the backend driver is full.
22. The apparatus according to claim 20 or 21, wherein said reading unit is in reading The mode that the receiving thread needs to be in, specifically for reading the mode that the receiving thread needs to be in when it is allowed to read the mode that the receiving thread needs to be in.
23. The device according to claim 20 or 21, wherein the reading unit is in a mode in which the receiving thread needs to be read, specifically for:

    When it is forbidden to read the mode that the receiving thread needs to be in, after waiting for a predetermined time, try again to read the mode that the receiving thread needs to be in until the mode in which the receiving thread needs to be read is allowed to be read.
24. The device according to any one of claims 20 to 23, further comprising:

    a second notification unit, configured to: after the determining unit determines that the skb queue is empty or determines that the shared memory between the front end driver of the user virtual machine DomU and the back end driver of the privileged virtual machine Dom0 is full, the reading The unit reads that the receiving thread needs to be in the non-polling mode and the determining unit determines that the mode that the previous reading to the receiving thread needs to be in the polling mode, and sends the notification to the front end driver to notify the The mode of the receiving thread is changed from polling mode to notification information in non-polling mode.
25. A data processing device in a virtualization platform, wherein the data processing device is applied to a front end driver of a user virtual machine DomU, including:

    a processing unit, configured to generate a first data request and place a shared memory between the front end driver and a backend driver of the privileged virtual machine Dom0;

    a sending unit, configured to: when the processing unit determines that a mode in which the receiving thread of the privileged virtual machine Dom0 is in a polling mode, does not need to send a wakeup request to the receiving thread of the Dom0, where the polling mode is used to identify the receiving thread In a non-sleep state.
26. The device according to claim 25, wherein the processing unit is further configured to generate a second data request to be placed in the shared memory between the front end driver and the back end driver;

    Also includes:

    a receiving unit, configured to receive, by the receiving thread, notification information for notifying that the mode of the receiving thread is changed from a polling mode to a non-polling mode;

    The sending unit is further configured to: when the receiving unit receives the notification information, send a wakeup request for waking up the receiving thread to the receiving thread, where the non-polling mode is used to identify the receiving The thread is in a sleep state when the skb queue is empty or when the shared memory between the front end driver of the user virtual machine DomU and the backend driver is full.

Images