CN116841697B - Method for processing MMIO request, electronic device and storage medium - Google Patents

Abstract

The application provides a method for processing MMIO requests, an electronic device and a storage medium. The method comprises the following steps: in response to receiving an MMIO request from a virtual machine, setting, via a virtual machine driver, an indication variable corresponding to the MMIO request to a first value; responsive to the indicator variable being a first value, obtaining event information related to the MMIO request via a first thread and storing to an event queue; reading the event information from the event queue via a second thread; and processing the MMIO request according to the event information via the second thread, wherein the first thread and the second thread are associated with an application for running the virtual machine.

Description

Method for processing MMIO request, electronic device and storage medium

Technical Field

The present application relates to the field of chip verification technologies, and in particular, to a method for processing an MMIO request, an electronic device, and a storage medium.

Background

A hardware simulation tool (e.g., a prototype verification board or hardware simulator (emulator)) may prototype (prototype) and debug a logic system design that includes one or more modules. The logic System design may be, for example, a design for an integrated circuit (ApplicationSpecificIntegratedCircuit, ASIC for short) or a System-On-Chip (SOC) for special applications. Thus, the logic system design being tested in the simulation tool may also be referred to as a design under test (DesignUnderTest, DUT for short). The simulation tool may simulate the design under test by one or more configurable components, such as a field programmable gate array (FieldProgrammableGateArray, abbreviated FPGA), including performing various operations on the design under test to test and verify the functionality of the various modules of the design under test prior to fabrication. The design to be tested and various peripherals can be tested to be used as a complete system to run by externally connecting various peripheral daughter cards on the simulation tool.

One way to connect a peripheral daughter card to a host is to use QEMU to virtualize one or more hosts, and these virtual hosts may invoke the peripheral daughter card through a Memory Mapped IO (MMIO) address. For example, if the chip design is a peripheral chip, then the QEMU is used to virtualize the host and cooperate with the peripheral chip to test if the chip design is correct.

Disclosure of Invention

A first aspect of the application provides a method of handling MMIO requests. The method comprises the following steps: in response to receiving an MMIO request from a virtual machine, setting, via a virtual machine driver, an indication variable corresponding to the MMIO request to a first value; responsive to the indicator variable being a first value, obtaining event information related to the MMIO request via a first thread and storing to an event queue; reading the event information from the event queue via a second thread; and processing the MMIO request according to the event information via the second thread, wherein the first thread and the second thread are associated with an application for running the virtual machine.

A second aspect of the present application provides an electronic device, comprising: a memory for storing a set of instructions; and at least one processor configured to execute the set of instructions to cause the electronic device to perform the method of the first aspect.

A third aspect of the application provides a non-transitory computer readable storage medium storing a set of instructions of a computer for, when executed, causing the computer to perform the method of the first aspect.

The method of the embodiment of the application ensures that the virtual machine driver avoids the virtual machine driver from exiting in a mode of transferring MMIO requests to QEMU application for processing. Thus, even if a large number of MMIO requests are gushed into the virtual machine driver, the QEMU application can sequentially process the MMIO requests according to the sequence of the requests entering the queue. The virtual machine driver can continue to process other requests without exiting for MMIO requests because MMIO requests are not processed, so that the overall operation efficiency of the system is improved.

Drawings

In order to more clearly illustrate the technical solutions of the present application or related art, the drawings that are required to be used in the description of the embodiments or related art will be briefly described below, and it is apparent that the drawings in the following description are only embodiments of the present application, and other drawings may be obtained according to the drawings without inventive effort to those of ordinary skill in the art.

Fig. 1 shows a schematic diagram of an exemplary host according to an embodiment of the present application.

FIG. 2 shows a schematic diagram of a simulation system in accordance with an embodiment of the present application.

FIG. 3 illustrates a schematic diagram of processing MMIO requests between a driver and guest operating systems in accordance with an embodiment of the application

FIG. 4 illustrates a flow chart of a method for handling MMIO requests in accordance with an embodiment of the present application.

Detailed Description

The present application will be further described in detail below with reference to specific embodiments and with reference to the accompanying drawings, in order to make the objects, technical solutions and advantages of the present application more apparent.

It is to be noted that unless otherwise defined, technical or scientific terms used herein should be taken in a general sense as understood by one of ordinary skill in the art to which the present application belongs. The terms "first," "second," and the like, as used herein, do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The word "comprising" and the like means that elements or items preceding the word are included in the element or item listed after the word and equivalents thereof without precluding other elements or items. The term "coupled" and the like are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

Fig. 1 shows a schematic structure of a host 100 according to an embodiment of the present application. The host 100 may be an electronic device running an emulation system. As shown in fig. 1, the host 100 may include: processor 102, memory 104, network interface 106, peripheral interface 108, and bus 110. Wherein the processor 102, the memory 104, the network interface 106, and the peripheral interface 108 are communicatively coupled to each other within the electronic device via a bus 110.

The processor 102 may be a central processing unit (Central Processing Unit, CPU), an image processor, a neural Network Processor (NPU), a Microcontroller (MCU), a programmable logic device, a Digital Signal Processor (DSP), an Application SPECIFIC INTEGRATED Circuit (ASIC), or one or more integrated circuits. The processor 102 may be used to perform functions related to the techniques described herein. In some embodiments, processor 102 may also include multiple processors integrated as a single logical component. As shown in fig. 1, the processor 102 may include a plurality of processors 102a, 102b, and 102c.

The memory 104 may be configured to store data (e.g., instruction sets, computer code, intermediate data, etc.). In some embodiments, the simulation test system used to simulate the test design may be a computer program stored in memory 104. As shown in fig. 1, the data stored by the memory may include program instructions (e.g., program instructions for implementing the error localization method of the present application) as well as data to be processed (e.g., the memory may store temporary code generated during compilation). The processor 102 may also access program instructions and data stored in the memory and execute the program instructions to perform operations on the data to be processed. The memory 104 may include volatile storage or nonvolatile storage. In some embodiments, memory 104 may include Random Access Memory (RAM), read Only Memory (ROM), optical disks, magnetic disks, hard disks, solid State Disks (SSD), flash memory, memory sticks, and the like.

The network interface 106 may be configured to provide communication with other external devices to the host 100 via a network. The network may be any wired or wireless network capable of transmitting and receiving data. For example, the network may be a wired network, a local wireless network (e.g., bluetooth, wiFi, near Field Communication (NFC), etc.), a cellular network, the internet, or a combination of the foregoing. It will be appreciated that the type of network is not limited to the specific examples described above. In some embodiments, network interface 106 may include any combination of any number of Network Interface Controllers (NICs), radio frequency modules, receivers, modems, routers, gateways, adapters, cellular network chips, etc.

The peripheral interface 108 may be configured to connect the host 100 with one or more peripheral devices to enable information input and output. For example, the peripheral devices may include input devices such as keyboards, mice, touchpads, touch screens, microphones, various types of sensors, and output devices such as displays, speakers, vibrators, and indicators.

Bus 110 may be configured to transfer information between the various components of host 100 (e.g., processor 102, memory 104, network interface 106, and peripheral interface 108), such as an internal bus (e.g., processor-memory bus), an external bus (USB port, PCI-E bus), etc.

It should be noted that, although the above electronic device architecture only shows the processor 102, the memory 104, the network interface 106, the peripheral interface 108, and the bus 110, in a specific implementation, the electronic device architecture may also include other components necessary to achieve proper operation. Furthermore, it will be understood by those skilled in the art that the electronic device architecture may include only the components necessary for implementing the embodiments of the present application, and not all the components shown in the drawings.

FIG. 2 shows a schematic diagram of a simulation system 200 according to an embodiment of the application.

As shown in FIG. 2, the simulation system 200 may include a simulation tool 202 and a host 100 coupled to the simulation tool 202.

Simulation tool 202 is a hardware system for simulating a Design Under Test (DUT). Simulation tool 202 may be a prototype verification board or a hardware simulator (emulator). One design under test may include multiple modules. The design under test may be combinational logic, sequential logic, or a combination of the two. The simulation tool 202 may include one or more configurable circuits (e.g., FPGAs) for simulating a design under test.

The simulation tool 202 may include an interface unit 2022 for communicatively coupling with the host 100 for communication between the host 100 and the simulation tool 202. In some embodiments, interface unit 2022 may include one or more interfaces with electrical connection capabilities. For example, the interface unit 2022 may include an RS232 interface, a USB interface, a LAN interface, an optical fiber interface, IEEE1394 (firewire interface), and the like. In some embodiments, the interface unit 2022 may be a wireless network interface. For example, the interface unit 2022 may be a WIFI interface, a bluetooth interface, or the like.

The host 100 may transmit compiled DUTs, debug instructions, etc. to the simulation tool 202 via the interface unit 2022. The simulation tool 202 may also transmit simulation data or the like to the host 100 via the interface unit 2022.

The simulation tool 202 may also include a memory 2024 for storing simulation data (e.g., various signal values) generated by the design under test during the simulation process. In some embodiments, the signal values generated by the design under test during the simulation process may be directly read by the host 100. It will be appreciated that the memory 2024 may also be provided by the stand-alone simulation tool 202, for example, using an external memory.

The simulation tool 202 may also include an FPGA 2026 for hardware implementation of the logic system design onto the FPGA. It is understood that the simulation tool 202 may include a plurality of FPGAs, which are only examples.

In addition to being connected to the host 100, the emulation tool 202 can also be connected to one or more daughter cards 204 via an interface unit 2022.

The daughter card is used to provide peripherals to the DUT to build a complete electronic system when prototype verification is performed using simulation tool 202. Prototype verification refers to a verification mode for restoring the actual use scene of a chip as far as possible before chip streaming, and verifying whether the chip functions are accurate and complete. The daughter cards 204 may include memory daughter cards (e.g., providing DDR memory interfaces), communication daughter cards (e.g., providing various network interfaces or wireless network card interfaces), and the like.

The host 100 may be used to configure the simulation tool 202 to simulate a design under test. The design under test may be a complete logic system design or one or more modules of a complete logic system design. In some embodiments, host 100 may be a virtual host in a cloud computing system. The logic System design (e.g., ASIC or System-On-Chip) may be designed by a hardware description language (e.g., verilog, VHDL, system C, or System Verilog).

The host 100 may receive a request from a user to debug a design under test. As described above, the design under test may include one or more modules. Description of the design under test may be accomplished in a hardware description language. The host 100 may synthesize based on the description of the design under test to generate, for example, a gate level netlist (not shown) of the design under test. The gate level circuit netlist of the design under test may be loaded into simulation tool 202 for operation, which in turn may form a circuit structure corresponding to the design under test in simulation tool 202. Accordingly, the circuit structure of the design under test can be obtained from this description, and accordingly, the circuit structure of each block in the design under test can also be obtained similarly.

As described above, host 100 may use a QEMU application to virtualize one or more systems (or devices) and these virtual systems may invoke peripheral daughter cards through Memory Mapped IO (MMIO) addresses. These virtualized systems may also be referred to as Guest OS (Guest operating system). The operating system of the Host 100, also referred to as Host OS, interacts with the guest operating system or systems via Kernel based Virtual Machine (KVM) and VTx drivers.

Because of the limited device addresses of the host operating system, memory Mapped IO (MMIO) techniques are typically used to extend the addresses that can be used by the device (e.g., guest operating system). In this way MMIO requests can be handled directly by the driver of the host operating system.

At this time, when the virtual guest operating system attempts to access the device, it may happen that the MMIO address of the device is out of the range of the host operating system, so that the KVM driver may exit (also referred to as MMIO exit), and the guest operating system generated by the QEMU directly processes the IO request, and restarts the KVM after the IO request processing is completed.

The exit of the KVM and the IO request routing QEMU processing may result in overall performance degradation.

Therefore, how to increase the processing speed of MMIO requests directly relates to the overall performance of the hardware simulation tool is a technical problem to be solved.

In light of the foregoing, the present inventors have noted that in the existing MMIO exit processing manner, an obvious processing manner is adopted, that is, the guest operating system application issues an operation instruction for the IO, but if the IO operation is beyond the KVM range of the host operating system, the KVM running on the host operating system exits and returns the request to the guest operating system for direct processing. The inventors have appreciated that if the KVM can pass the IO operation instructions and their associated information to the guest operating system without exiting and pass the guest operating system to process the IO operation instructions, the KVM exit problem caused by MMIO can be solved.

Based on the above, the embodiment of the application provides a method, a device and a storage medium for processing MMIO requests.

FIG. 3 illustrates a schematic diagram of processing (300) MMIO requests between a virtual machine driver and a QEMU application, according to an embodiment of the application.

As described above, the KVM driver of the host operating system, upon receiving an MMIO request, determines whether the MMIO request is outside of its own address range. If the address range (sometimes also called page fault) is exceeded, it is conventional practice for the KVM to attempt to solve the problem of exceeding the address range based on the setting of KVM_SET_USER_MEMORY_REGION. If the failure is resolved, the virtual machine driver (i.e., KVM driver) is exited and the MMIO request is handed back to the guest operating system for processing.

In some embodiments of the present application, after receiving the MMIO request 302, the virtual machine driver 310 may first determine whether the MMIO request 302 is outside the address range according to conventional practice. If, at step 312, virtual machine driver 310 determines that MMIO request 302 is outside of the address range, then an indicator variable 304 is set to a first value (e.g., 1). It will be appreciated that the value of the indicator variable may be set according to the user design and is not limited to 1. Virtual machine driver 310 may be a VTx driver.

In other embodiments, the virtual machine driver 310 no longer determines whether the MMIO request 302 is outside of the address range, but sets the indicator variable 304 to the first value in direct response to receiving the MMIO request 302. In this way, virtual machine driver 310 does not actually process MMIO request 302.

In QEMU application 320, two processes 322 and 326 are running. Process 322 continuously checks the indicated variable 304. When process 322 determines that the indicator variable 304 is the first value, process 322 retrieves information related to MMIO request 302 from virtual machine driver 310 and saves it as event information 3242 in event queue 324 within QEMU application 320. Event queue 324 may be a first-in-first-out (FIFO) queue. It is to be appreciated that the process 322 can set the indicator variable 304 to a second value (e.g., 0) after obtaining the value of the indicator variable 304. It is to be appreciated that QEMU references 320 described above are merely examples, and that other types of applications for generating virtual devices are possible.

The event information 3242 may be a structure. Exemplary codes for the structures are given below

struct {

_u64 phys_addr;

_u8 data[8];

_u32 len;

_u8 is_write;

} mmio;

As indicated above, event information 3242 may include a physical head address of MMIO request 302, data to be operated on, an address length of the request operation, and a flag of whether the request is a write operation. It will be appreciated that although virtual machine driver 310 cannot handle the physical address of MMIO request 302, the guest operating system generated by QEMU application 320 is processable.

The process 326 continually checks the event queue 324. If event queue 324 is not empty, process 326 retrieves event information from event queue 324 and processes MMIO requests corresponding to the event information accordingly.

The method of the embodiment of the application ensures that the virtual machine driver avoids the virtual machine driver from exiting in a mode of transferring MMIO requests to QEMU application for processing. In this way, QEMU application 320 can process requests sequentially into queue 324 even if there are a large number of MMIO requests in-rush. The virtual machine driver 310 can continue to process other requests without exiting for MMIO requests, thereby improving the overall operation efficiency of the system.

The embodiment of the application also provides a method for processing the MMIO request.

Fig. 4 illustrates a flow diagram of a method 400 for handling MMIO requests, wherein the method 400 may be performed by a host 100 as shown in fig. 1, in accordance with an embodiment of the present application. The method 400 may include the following steps.

In step 402, in response to receiving an MMIO request from a virtual machine (e.g., guest operating system), an indication variable (e.g., indication variable 304 of FIG. 3) corresponding to the MMIO request is set to a first value via a virtual machine driver (e.g., virtual machine driver 310 of FIG. 3).

In some embodiments, setting the indication variable corresponding to the MMIO request to the first value further comprises: determining whether the operation address of the MMIO request exceeds the address range of the virtual machine driver; and setting the indicating variable to the first value in response to the operating address of the MMIO request exceeding the address range of the virtual machine driver.

The virtual machine driver remains running after the indicated variable is set to a first value. Thus, the virtual machine driver does not exit after receiving the MMIO request, and the operation efficiency of the system is not affected.

In step 404, in response to the indicator variable being a first value, event information (e.g., event information 3242 of FIG. 3) related to the MMIO request is obtained via a first thread (e.g., process 322 of FIG. 3) and stored to an event queue (e.g., event queue 324 of FIG. 3).

The event information includes at least one of a physical head address of the MMIO request, data to be operated on, an address length, or a flag of whether the MMIO request is a write operation. The event queue is a first-in first-out queue.

In some embodiments, the value of the indicated variable of the MMIO request is indicated via the first line Cheng Huoqu; and determining, via the first thread, whether the value of the indicated variable is a first value.

At step 406, the event information is read from the event queue via a second thread (e.g., process 324 of FIG. 3).

At step 408, the MMIO request is processed according to the event information via the second thread, wherein the first thread and the second thread are associated with an application (e.g., QEMU) for running the virtual machine. That is, the application for running the virtual machine is a QEMU application.

The embodiment of the application also provides an electronic device. The electronic device may be the host 100 of fig. 1. The host 100 may include a memory for storing a set of instructions; and at least one processor configured to execute the set of instructions to cause the electronic device to perform the method 400.

Embodiments of the present application also provide a non-transitory computer readable storage medium. The non-transitory computer readable storage medium stores a set of instructions for a computer that, when executed, cause the computer to perform the method 400.

The foregoing describes some embodiments of the present application. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Those of ordinary skill in the art will appreciate that: the discussion of any of the embodiments above is merely exemplary and is not intended to suggest that the scope of the application (including the claims) is limited to these examples; the technical features of the above embodiments or in the different embodiments may also be combined within the idea of the application, the steps may be implemented in any order and there are many other variations of the different aspects of the application as described above, which are not provided in detail for the sake of brevity.

While the application has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of those embodiments will be apparent to those skilled in the art in light of the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the embodiments discussed.

The present application is intended to embrace all such alternatives, modifications and variances which fall within the broad scope of the appended claims. Therefore, any omission, modification, equivalent replacement, improvement, etc. of the present application should be included in the scope of the present application.

Claims (7)

1. A method of processing MMIO requests, comprising:

in response to a virtual machine receiving an MMIO request, setting an indication variable corresponding to the MMIO request to a first value through a virtual machine driver, wherein the virtual machine driver keeps running after the indication variable is set to the first value;

Responsive to the indicator variable being a first value, obtaining event information related to the MMIO request from the virtual machine driver via a first thread and storing to an event queue;

reading the event information from the event queue via a second thread; and

Processing the MMIO request according to the event information via the second thread, wherein the first thread and the second thread are associated with an application for running the virtual machine, wherein setting an indicator variable corresponding to the MMIO request to a first value further comprises:

Determining whether the operation address of the MMIO request exceeds the address range of the virtual machine driver;

And setting the indicating variable to the first value in response to the operating address of the MMIO request exceeding the address range of the virtual machine driver.

2. The method of claim 1, further comprising:

indicating a value of an indication variable of the MMIO request via the first line Cheng Huoqu; and

A determination is made via the first thread as to whether the value of the indicated variable is a first value.

3. The method of claim 1, wherein the event information comprises at least one of a physical head address of the MMIO request, data to operate on, an address length, or a flag of whether the MMIO request is a write operation.

4. The method of claim 1, wherein the event queue is a first-in first-out queue.

5. The method of claim 1, wherein the application for running the virtual machine is a QEMU application.

6. An electronic device includes

A memory for storing a set of instructions; and

At least one processor configured to execute the set of instructions to cause the electronic device to perform the method of any one of claims 1-5.

7. A non-transitory computer readable storage medium storing a set of instructions of a computer for, when executed, causing the computer to perform the method of any one of claims 1-5.