Solid state disk controller, control method thereof, solid state disk, and solid state disk system

Abstract

The application relates to the field of solid state disk applications, and discloses a solid state disk controller and a control method thereof, a solid state disk, and a solid state disk system. A virtual machine is arranged in the solid state disk controller to run solid state disk firmware, and an emulator is arranged to simulate the hardware module of the solid state disk controller. When the solid state disk firmware sends an access request to the hardware module, the access request is intercepted by the virtual machine and forwarded to the emulator to simulate the behavior of the hardware module. On the one hand, the virtual machine and the emulator arranged in the solid state disk controller can decouple software and hardware, realize the running of the solid state disk firmware on the virtual machine, and be beneficial to realizing the customized development of the solid state disk. On the other hand, the secondary development of a third party can be realized based on the emulator, and the development efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of solid state disk applications, and in particular to a solid state disk controller and a control method thereof, a solid state disk, and a solid state disk system. BACKGROUND

[0002] A solid state disk (SSD) is a hard disk made of a solid-state electronic storage chip array. The solid state disk includes a control unit and a storage unit (flash memory chip or DRAM memory chip).

[0003] At present, the software development of the solid state disk adopts a firmware development mode based on multi-core and tight coupling of software and hardware. Most of the software is developed by the original manufacturer of the master control chip, and then a large number of samples are strictly tested for a long time to meet the standard of mass production. A large amount of manpower, material resources and testing costs are involved. Once the software is modified, a large amount of testing must be repeated. In this mode, it is difficult for a third party to develop product-level software based on the original master control chip. The development of an enterprise-level SSD product software takes a long time to produce and requires a large amount of research and development costs. Therefore, most of the existing SSD products are developed by the original manufacturer of the master control chip, and the proportion of SSD manufacturers that simply develop independent software is relatively small.

[0004] At the same time, there is a large demand for secondary development of SSDs in the market. Under the current reality of the SSD software and hardware architecture, it is necessary to entrust the original manufacturer of the SSD to develop, resulting in high development cost and poor timeliness. SUMMARY

[0005] The embodiments of the present application provide a solid state disk controller and a control method thereof, a solid state disk, and a solid state disk system to reduce the development cost and improve the development efficiency.

[0006] The embodiments of the present application provide the following technical solutions:

[0007] In a first aspect, the embodiments of the present application provide a solid state disk controller, comprising:

[0008] a virtual machine configured to run a solid state disk firmware;

[0009] a simulator connected to the virtual machine and configured to simulate at least one hardware module of the solid state disk controller;

[0010] When the solid state disk firmware sends an access request to the hardware module, the virtual machine intercepts the access request and sends the access request to the simulator, so that the simulator simulates the behavior of the hardware module.

[0011] In some embodiments, the solid-state drive controller includes multiple processing units, the multiple processing units support virtualization, and the multiple processing units include multiple run levels;

[0012] The virtual machine creates multiple virtual processing units, which are used to run the solid-state drive firmware.

[0013] In some embodiments, the solid-state drive firmware corresponds to an image file;

[0014] The simulator is used to load image files into the virtual processing unit so that the virtual processing unit can run solid-state drive firmware.

[0015] In some embodiments, the solid-state drive controller includes multiple hardware modules, wherein the hardware modules include at least one of a PCIe module, an NVMe module, a buffer management module, an ECC module, and a flash memory management module;

[0016] The simulator includes multiple virtual hardware modules, each of which corresponds to a hardware module of the simulated solid-state drive controller. The virtual hardware modules include at least one of the following: virtual PCIe module, virtual NVMe module, virtual buffer management module, virtual ECC module, and virtual flash management module.

[0017] In some embodiments, operation commands are sent to the virtual machine through a virtual PCIe module.

[0018] In some embodiments, the virtual machine includes:

[0019] The virtual machine monitor is used to intercept access requests sent by the solid-state drive firmware to the hardware module.

[0020] In some embodiments, the solid-state drive controller further includes:

[0021] The interrupt controller, connected to the processing unit of the solid-state drive controller, is used to manage and control maskable interrupts, determine the priority of maskable interrupts, and send interrupt signals to the processing unit.

[0022] Secondly, embodiments of this application provide a solid-state drive, comprising:

[0023] Such as the solid-state drive controller in the first aspect;

[0024] At least one flash memory medium is communicatively connected to the solid-state drive controller.

[0025] Thirdly, embodiments of this application provide a solid-state drive system, including:

[0026] Such as solid-state drives in the second aspect;

[0027] The host computer is connected to a solid-state drive for communication.

[0028] Fourthly, embodiments of this application provide a control method for a solid-state drive controller, applied to the solid-state drive controller as described in the first aspect, the method comprising:

[0029] If a page fault is generated when an operation instruction is executed by a virtual processing unit, and the data page accessed by the operation instruction does not exist in memory;

[0030] The virtual machine intercepts the page fault and sends it to the emulator;

[0031] After the simulator receives a page fault, it simulates the behavior of the hardware module.

[0032] In some embodiments, page faults include memory page faults and memory-mapped page faults;

[0033] If the page fault is a memory page fault, the emulator maps the memory page to the virtual machine address to simulate the behavior of the hardware module;

[0034] If the page fault is a memory-mapped page fault, then the emulator simulates the behavior of the hardware module based on the type of operation instruction, specifically including:

[0035] If the operation instruction is a read operation, the simulator returns the read data to the virtual machine;

[0036] If the operation instruction is a write operation, the simulator will simulate the behavior of the hardware module in response to the write operation.

[0037] Fifthly, embodiments of this application also provide a non-volatile computer-readable storage medium storing computer-executable instructions for enabling a solid-state drive to execute the control method of the solid-state drive controller described above.

[0038] The beneficial effects of the embodiments of this application are as follows: In contrast to the prior art, the solid-state drive controller provided in the embodiments of this application includes a virtual machine for running solid-state drive firmware; a simulator connected to the virtual machine for simulating at least one hardware module of the solid-state drive controller; wherein, when the solid-state drive firmware sends an access request to the hardware module, the virtual machine intercepts the access request and sends the access request to the simulator, so that the simulator simulates the behavior of the hardware module.

[0039] By setting up a virtual machine on the SSD controller to run the SSD firmware and setting up an emulator to simulate the hardware module of the SSD controller, the virtual machine intercepts the access request sent by the SSD firmware to the hardware module and forwards it to the emulator to simulate the behavior of the hardware module. On the one hand, by setting up a virtual machine and an emulator in the SSD controller, the software and hardware can be decoupled, and the SSD firmware can run on the virtual machine, which is conducive to the customized development of SSDs. On the other hand, it enables third parties to perform secondary development based on the emulator, improving development efficiency. Attached Figure Description

[0040] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0041] Figure 1 This is a schematic diagram of the structure of a solid-state drive provided in an embodiment of this application;

[0042] Figure 2 This is a schematic diagram of a solid-state drive controller provided in an embodiment of this application;

[0043] Figure 3 This is a schematic diagram of the architecture of a solid-state drive controller provided in an embodiment of this application;

[0044] Figure 4 This is a schematic diagram of the structure of a solid-state drive controller provided in an embodiment of this application;

[0045] Figure 5 This is a schematic diagram of another solid-state drive controller provided in an embodiment of this application;

[0046] Figure 6 This is a schematic diagram of the software architecture of a virtualized hardware platform provided in an embodiment of this application;

[0047] Figure 7 This is a schematic diagram illustrating the interaction between a simulator and a virtual machine, provided in an embodiment of this application.

[0048] Figure 8 This is a schematic diagram of a simulator provided in an embodiment of this application;

[0049] Figure 9 This is a flowchart illustrating a control method for a solid-state drive controller provided in an embodiment of this application;

[0050] Figure 10 This is a schematic diagram of the structure of a solid-state drive system provided in an embodiment of this application. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0052] Furthermore, the technical features involved in the various embodiments of this application described below can be combined with each other as long as they do not conflict with each other.

[0053] A typical solid state drive (SSD) usually includes a solid state drive controller (main controller), flash memory array, cache unit, and other peripheral units.

[0054] Solid-state drives (SSDs) are typically controlled by an SSD controller, also known as the main controller, which acts as the control and processing unit to manage the internal system of the SSD. NAND flash arrays serve as storage units, used to store data, including user data and system data. A flash array generally presents multiple channels (CH), with each channel independently connecting to a group of NAND flash chips, such as CH0 / CH1…CHx. NAND flash memory is characterized by the requirement to erase before writing, and each flash chip has a limited number of erase cycles. A cache unit is used to cache the mapping table; the cache unit is typically Dynamic Random Access Memory (DRAM). Other peripheral units may include sensors, registers, and other components.

[0055] Currently, SSD controller architecture adopts a design and development approach that tightly couples software and chip hardware. Customers and third parties usually need the original controller chip manufacturer to develop custom software, resulting in high development costs and insufficient timeliness.

[0056] Based on this, embodiments of this application provide a solid-state drive controller and its control method, a solid-state drive, and a solid-state drive system to reduce development costs and improve development efficiency.

[0057] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings:

[0058] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a solid-state drive provided in an embodiment of this application.

[0059] like Figure 1 As shown, the solid-state drive 100 includes a flash memory medium 110 and a solid-state drive controller 120 connected to the flash memory medium 110. The solid-state drive 100 communicates with the host 200 via wired or wireless means to achieve data exchange.

[0060] Flash memory 110, as the storage medium of solid-state drive 100, is also called flash memory, flash, flash memory or flash chip. It is a type of storage device and is a non-volatile memory that can retain data for a long time without a current supply. Its storage characteristics are equivalent to those of a hard drive, which makes flash memory 110 the basis for the storage medium of various portable digital devices.

[0061] In this context, the flash memory medium 110 can be a Nand flash array. The flash array serves as a storage unit for storing user data and system data, typically presenting multiple flash channels (CH), with each channel independently connected to a group of NAND flash chips. Nand flash uses a single transistor as the storage unit for binary signals. Its structure is very similar to ordinary semiconductor transistors, but the difference lies in the addition of a floating gate and a control gate to the single transistor. The floating gate stores electrons, its surface is covered by a layer of silicon oxide insulator, and it is coupled to the control gate via a capacitor. When negative electrons are injected into the floating gate under the action of the control gate, the storage state of the Nand flash single crystal changes from "1" to "0". When the negative electrons are removed from the floating gate, the storage state changes from "0" to "1". The insulator covering the surface of the floating gate traps the negative electrons in the floating gate, thus achieving data storage. In other words, the storage unit of Nand FLASH is a floating gate transistor, which stores data in the form of charge. The amount of stored charge is related to the magnitude of the voltage applied to the floating gate transistor.

[0062] A Nand flash memory includes at least one chip, each chip consists of several physical blocks, and each physical block includes several physical pages. A physical block is the smallest unit for performing an erase operation in Nand flash memory, and a physical page is the smallest unit for performing read and write operations. The capacity of a Nand flash memory is equal to the number of its physical blocks multiplied by the number of physical pages contained in a physical block multiplied by the capacity of a single physical page. Specifically, flash memory media 10 can be classified into SLC, MLC, TLC, and QLC according to the different voltage levels of the storage cells.

[0063] Solid-state drive controller 120 includes a data converter 121, a processor 122, a cache 123, a flash memory controller 124, and an interface 125.

[0064] Data converter 121, connected to processor 122 and flash memory controller 124 respectively, is used to convert binary data to hexadecimal data and vice versa. Specifically, when flash memory controller 124 writes data to flash memory medium 110, data converter 121 converts the binary data to be written into hexadecimal data before writing it to flash memory medium 110. When flash memory controller 124 reads data from flash memory medium 110, data converter 121 converts the hexadecimal data stored in flash memory medium 110 into binary data, and then reads the converted data from the binary data page register. Data converter 121 may include a binary data register and a hexadecimal data register. The binary data register can be used to store data converted from hexadecimal to binary, and the hexadecimal data register can be used to store data converted from binary to hexadecimal.

[0065] The processor 122 is connected to the data converter 121, the cache 123, the flash memory controller 124, and the interface 125, respectively. The processor 122 can be connected to the data converter 121, the cache 123, the flash memory controller 124, and the interface 125 via a bus or other means. The processor is used to run non-volatile software programs, instructions, and modules stored in the cache 123, thereby implementing any method embodiment of this application.

[0066] Cache 123 is primarily used to cache read / write instructions sent by host 200 and read or write data obtained from flash memory medium 110 according to the read / write instructions sent by host 200. Cache 123, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Cache 123 may include a program storage area, which may store the operating system and application programs required for at least one function. Furthermore, cache 123 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, cache 123 may optionally include memory remotely located relative to processor 124. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The register 123 can be a static random access memory (SRAM), a tightly coupled memory (TCM), or a double data rate synchronous dynamic random access memory (DDR SRAM).

[0067] The flash memory controller 124 is connected to the flash memory medium 110, the data converter 121, the processor 122, and the cache 123. It is used to process the communication protocol with the flash memory, such as: accessing the back-end flash memory medium 110, managing various parameters and data I / O of the flash memory medium 110; or, providing access interfaces and protocols to implement the corresponding SAS / SATA target protocol or NVMe protocol, obtaining I / O commands issued by the host 200 and decoding and generating internal private data results for execution.

[0068] Interface 125 connects host 200, data converter 121, processor 122, and buffer 123. It is used to receive data sent by host 200 or data sent by processor 122, so as to realize data transmission between host 200 and processor 122. Interface 125 can be SATA-2 interface, SATA-3 interface, SAS interface, MSATA interface, PCI-E interface, NGFF interface, CFast interface, SFF-8639 interface, and M.2 NVME / SATA protocol.

[0069] Please refer to the following: Figure 2 , Figure 2 This is a schematic diagram of a solid-state drive controller provided in an embodiment of this application; wherein, the solid-state drive controller belongs to the aforementioned solid-state drive.

[0070] like Figure 2 As shown, the solid-state drive controller includes: a PCIe interface controller 126, a dynamic random access memory controller 127, an NVMe interface controller 128, a processor 122, a peripheral module 129, a data path module 1210, and a flash memory controller 124.

[0071] The host interface controller, used to handle communication protocols with the host, includes: PCIe interface controller 126 and NVMe interface controller 128.

[0072] Specifically, the PCIe interface controller 126 is used to handle the PCIe communication protocol with the host.

[0073] Specifically, the Dynamic Random Memory Controller 127, or DDR controller, is used to handle the communication protocol with the Dynamic Random Memory.

[0074] Specifically, the NVMe interface controller 128 is used to handle the NVMe communication protocol.

[0075] Specifically, peripheral module 129 is used to handle other related communication protocols.

[0076] Specifically, the data path module 1210 is used for data path control and internal data flow processing, such as write cache management, and the flash memory controller 124 is used for flash memory data processing.

[0077] Please refer to the following: Figure 3 , Figure 3 This is a schematic diagram of the architecture of a solid-state drive controller provided in an embodiment of this application;

[0078] like Figure 3 As shown, the solid-state drive controller includes a processor that runs the solid-state drive firmware. This firmware is responsible for scheduling the reading and writing of data from the interface to the media. It also includes an embedded core flash media lifetime and reliability management scheduling algorithm, as well as some other internal SSD algorithms.

[0079] The processor comprises N CPU cores, designated Core1 to CoreN. These CPU cores form a software control path, and each CPU core corresponds to one or at least two hardware modules. It is understood that the relationship between a CPU core and a hardware module can be one-to-one, one-to-many, or many-to-one; this is not limited here.

[0080] The solid-state drive controller also includes multiple hardware modules, such as: PCIe module, NVMe module, buffer management module, ECC module, and flash memory management module.

[0081] Specifically, the PCIe module is used to handle the PCIe communication protocol with the host. PCIe (Peripheral Component Interconnect Express) is a standard protocol interface for communication (data exchange) with the host. PCIe is a high-speed serial computer expansion bus standard. PCIe belongs to high-speed serial point-to-point multi-channel high-bandwidth transmission. The connected devices are allocated dedicated channel bandwidth and do not share the bus bandwidth. It mainly supports functions such as active power management, error reporting, end-to-end reliable transmission, hot-plugging, and Quality of Service (QoS).

[0082] Specifically, the NVMe module handles the NVMe communication protocol with the host. NVMe is a communication protocol between the host and a solid-state drive (SSD). It belongs to a higher level in the protocol stack. As a command and application layer protocol, NVMe can theoretically be adapted to any interface protocol. However, the original counterpart of the NVMe protocol is PCIe. NVMe defines the commands for communication between the host and the SSD, and how these commands are executed.

[0083] Specifically, the Buffer Management (BM) module is used to manage the internal buffers of the solid-state drive.

[0084] Specifically, the ECC module is a data encoding / decoding unit used for data encoding, decoding, and ECC verification. It's understandable that flash memory inherently has an error rate; to ensure data integrity, ECC verification must be added to the original data during write operations—this is an encoding process. Similarly, when reading data, decoding is required for error detection and correction. If the number of erroneous bits exceeds the ECC's error correction capability, the data will be uploaded to the host in an "uncorrectable" form. The ECC encoding and decoding processes are handled by the ECC module.

[0085] Specifically, the flash management module, or NAND Flash Controller, is used to access the flash media and manage various parameters and data of the flash media.

[0086] It is understandable that hardware modules such as the PCIe module, NVMe module, buffer management module, ECC module, and flash memory management module constitute the data path of the solid-state drive controller, while the CPU core corresponding to the hardware module constitutes the software control path. The software running on the CPU core is tightly coupled with the hardware module to achieve optimal performance. This software running on the CPU core is also known as firmware.

[0087] However, firmware development based on multi-core, tightly coupled hardware and software is mostly developed and tested by the original manufacturer of the main control chip, resulting in high development costs and insufficient timeliness.

[0088] Therefore, this application provides a solid-state drive controller that decouples software from hardware, thereby reducing development costs and improving development efficiency.

[0089] For details, please refer to [link / reference]. Figure 4 , Figure 4 This is a schematic diagram of the structure of a solid-state drive controller provided in an embodiment of this application;

[0090] like Figure 4 As shown, the solid-state drive controller 300 includes: a virtual machine 310, an emulator 320, and a hardware module 330.

[0091] In this embodiment of the application, the virtual machine 310 is a kernel-based virtual machine, which refers to a kernel module of Linux that makes Linux a hypervisor.

[0092] In this embodiment of the application, the virtual machine 310 is used to run solid-state drive firmware. When the solid-state drive firmware accesses the hardware, the access request of the solid-state drive firmware is intercepted by the virtual machine and handed over to the simulator 320, so that the simulator 320 partially or completely simulates the function of the hardware module 330.

[0093] As is understandable, KVM is an open-source, Linux-native, full virtualization solution based on x86 hardware with virtualization extensions (Intel VT or AMD-V). In KVM, virtual machines are implemented as regular Linux processes and scheduled by the standard Linux scheduler; each virtual CPU of a virtual machine is implemented as a regular Linux process, allowing KVM to utilize existing Linux kernel functionalities. However, KVM itself does not perform any hardware emulation; applications need to configure the address space of a guest virtual server through the KVM interface and provide it with emulated I / O.

[0094] In this embodiment, the simulator 320 is used to simulate the function of at least one hardware module 330. The hardware modules to be simulated are divided into three types:

[0095] (1) Transparent transmission. Specifically, the simulator 320 directly transmits access requests or operation commands to the hardware module 330 without performing any processing. In this case, the simulator acts as an intermediary.

[0096] (2) Complete software simulation. Specifically, the simulator 320 completely simulates the functions of the hardware module 330, so that the simulator 320 can completely simulate the operation of the hardware module 330 without sending access requests or operation commands to the hardware module 330, that is, without calling the hardware module 330.

[0097] (3) Hybrid type. Specifically, the simulator 320 modifies the access request or operation command sent to the hardware module 330, transmits the modified access request or operation command to the hardware module 330, or obtains the command execution result of the hardware module 330 and modifies the command execution result.

[0098] Understandably, if users need to perform secondary development based on the simulator, such as modifying the command execution results of NVMe, a hybrid approach is used. If users do not need to perform secondary development, a pass-through approach is used. If users need to reuse hardware modules used by the SSD firmware, such as SPI flash, a fully software-simulated approach is used.

[0099] In this embodiment, the solid-state drive controller 300 includes multiple hardware modules, such as a PCIe module, an NVMe module, a buffer management module, an ECC module, a flash memory management module, and other hardware modules.

[0100] Please refer to the following: Figure 5 , Figure 5 This is a schematic diagram of another solid-state drive controller provided in an embodiment of this application;

[0101] The solid-state drive controller runs a Linux system.

[0102] like Figure 5 As shown, the solid-state drive controller includes:

[0103] Multiple processing units (Core1-N), in which the solid-state drive firmware runs;

[0104] Virtual machine;

[0105] Specifically, a virtual machine, or guest system, includes multiple virtual processing units, memory, drivers, etc., and runs in a restricted CPU mode.

[0106] Simulator;

[0107] Multiple hardware modules;

[0108] Specifically, the multiple hardware modules include a PCIe module, an NVMe module, a buffer management module, an ECC module, a flash memory management module, and a dynamic random access memory controller;

[0109] The flash memory management module is used to interface with the flash memory medium; the dynamic random access memory controller is used to interface with the dynamic random access memory.

[0110] To enable software customization for solid-state drives (SSDs), the SSD controller in this embodiment decouples software from hardware, wherein multiple processing units support virtualization; and the SSD firmware that originally ran in multiple processing units is run as a virtual machine.

[0111] By building a virtual machine in the solid-state drive (SSD) controller, the SSD firmware can run on the virtual machine, such as a Linux virtual machine. On this architecture, an emulator can be further built to intervene in the execution process of the SSD firmware. This allows for the implementation of customized functions required by users based on the emulator, which not only ensures the stability of the SSD firmware but also improves the flexibility of software development.

[0112] It should be noted that the solid-state drive controller in this embodiment supports virtualization, including: CPU virtualization, memory virtualization, interrupt virtualization, I / O virtualization, network card virtualization, hard disk virtualization, etc.

[0113] Specifically, CPU virtualization refers to multiple processing units supporting multiple operating levels. For example, the processing units in this solid-state drive controller use ARMV8 architecture CPUs to support four operating levels: EL0 to EL3.

[0114] Specifically, memory virtualization refers to the requirement that software running on virtual machines must be able to access memory through the hypervisor. The hypervisor is an intermediate software layer running between the underlying physical server and the operating system, allowing multiple operating systems and applications to share hardware. A hypervisor can also be called a virtual machine monitor (VMM). Hypervisors are a "meta" operating system within the virtual environment. They access all physical devices on the server, including disks and memory.

[0115] In this embodiment of the application, the solid-state drive controller further includes:

[0116] The memory management unit (MMU) handles memory access requests from the processing unit of the solid-state drive (SSD) controller. The MMU also handles memory access requests from the central processing unit (CPU), including virtual address to physical address translation (virtual memory management), memory protection, and CPU cache control. In this embodiment, the MMU translates the virtual address of the running program into the actual physical address using page tables. In virtual machine mode, the MMU's page tables perform two address translations in a single lookup: one to translate the virtual address of the guest program into the guest's physical address, and another to translate the guest's physical address into a real physical address.

[0117] Specifically, interrupt virtualization refers to handling interrupt events through an interrupt controller. In this embodiment, the solid-state drive controller includes:

[0118] The interrupt controller, connected to the processing unit of the solid-state drive controller, is used to manage and control maskable interrupts, determine the priority of maskable interrupts, and send interrupt signals to the processing unit.

[0119] As we can understand, the interrupt controller acts as a proxy. Interrupt events generated by external devices do not directly enter the processing unit. Instead, they are sent to the interrupt controller, which then forwards them to the processing unit. The interrupt controller manages interrupt triggering conditions; a real system may have hundreds or even thousands of interrupt sources. Running a virtual machine requires that the host machine's interrupt controller has interrupt injection capabilities—that is, software injection of hardware interrupts into the guest machine (virtual machine). This is equivalent to performing an interrupt proxy, and the virtual machine is unaware that the interrupt was injected by the host machine's software.

[0120] Specifically, I / O virtualization refers to the fact that the access of guest virtual machines to hardware, such as I / O or MMIO, must be intercepted by the virtual machine monitor (Hypervisor) and implemented through page faults in the memory management unit (MMU).

[0121] Please refer to the following: Figure 6 , Figure 6 This is a schematic diagram of the software architecture of a virtualized hardware platform provided in an embodiment of this application;

[0122] like Figure 6 As shown, the software architecture includes an operating system kernel and an application layer.

[0123] The operating system kernel includes the Linux kernel, and the application layer includes the Linux Application.

[0124] The virtual machine runs on an operating system kernel, such as the Linux kernel. This virtual machine virtualizes multiple virtual processing units (vCPUs) to enable them to run solid-state drive (SSD) firmware. For example, the virtual machine might create multiple vCPUs, designated vCPU1 to vCPUn, with the number of vCPUs matching the number of processing units on the SSD controller. The virtual machine also provides memory virtualization, interrupt virtualization, and I / O virtualization. Each vCPU generates a corresponding file handle, and by accessing these file handles, each vCPU can be managed.

[0125] The emulator runs as an application at the application layer, such as LinuxApplication. The emulator is used to load the image file corresponding to the solid-state drive firmware into the virtual processing unit of the virtual machine for execution.

[0126] When the I / O request of the solid-state drive firmware is intercepted by the virtual machine, the virtual machine hands the I / O request over to the emulator for processing.

[0127] In this embodiment, the solid-state drive firmware corresponds to an image file, which can be a binary file. It is understood that firmware files are typically packaged in file compression types such as bin, zip, LZMA, and arj, with bin and zip being the most common. A bin file is a binary image, the most direct code image, recording the binary data to be stored in flash memory (machine code is essentially binary data). Binary files do not store data in ASCII code; they transfer the data stored in memory to the disk file without conversion. Therefore, it is also called a memory data image file. Because the information in the file is not character data but binary information in bytes, it is also called a byte file.

[0128] Please refer to the following: Figure 7 , Figure 7 This is a schematic diagram illustrating the interaction between a simulator and a virtual machine, provided in an embodiment of this application.

[0129] like Figure 7 As shown, the solid-state drive controller includes multiple hardware modules, wherein the hardware modules include at least one of a PCIe module, an NVMe module, a buffer management module, an ECC module, and a flash management module;

[0130] The simulator includes multiple virtual hardware modules, each of which corresponds to a hardware module of the simulated solid-state drive controller. The virtual hardware modules include at least one of the following: virtual PCIe module, virtual NVMe module, virtual buffer management module, virtual ECC module, and virtual flash management module.

[0131] Each hardware module in the solid-state drive controller corresponds to a virtual hardware module, which is simulated by an simulator. For example: Figure 7 As shown, the PCIe module corresponds to the virtual PCIe module (QOM_PCIe), the NVMe module corresponds to the virtual NVMe module (QOM_NVMe), the buffer management module corresponds to the virtual buffer management module (QOM_BM), the ECC module corresponds to the virtual ECC module (QOM_ECC), and the flash management module corresponds to the virtual flash management module (QOM_NFC).

[0132] In this embodiment, each virtual hardware module is implemented using an object-oriented programming interface. Specifically, each virtual hardware module is written in QOM (Qemu Object Model) within the QEMU environment. QOM is an object-oriented programming model implemented by Qemu. Qemu is written in C, which is a procedural programming language and cannot benefit from the advantages of object-oriented programming in design patterns for complex software systems. To address this issue, the Qemu community implemented an object-oriented programming interface, QOM, in C and successfully applied it to the management of Qemu device models. QOM is a programming interface for creating "classes" and "objects." This interface supports a flexible framework for users to create types and instantiate objects based on those types. It has the following characteristics: supports dynamic registration and creation of types; supports single inheritance (only one parent class); and supports multiple inheritance of types.

[0133] In this embodiment, each hardware module in the solid-state drive controller's hardware platform has a corresponding QOM software module in the QEMU emulator, such as QOM_PCIe, QOM_NVMe, and QOM_BM. The solid-state drive firmware is stored in a Linux file and transmitted to the virtual machine via the virtual bus module (QOM_SPI). When the virtual machine accesses the SPI address, it is intercepted by the KVM and the QEMU emulator's response function, i.e., the virtual bus module (QOM_SPI), is called. QOM_SPI then forwards the SPI flash image file to the virtual machine, allowing the virtual machine to obtain the SPI flash image file, which includes the solid-state drive firmware image file. It is understood that SPI is an abbreviation for Serial Peripheral Interface, a high-speed, full-duplex, synchronous communication bus.

[0134] It is understandable that each hardware module can correspond to a virtual hardware module in the simulator, so as to realize the simulation of the hardware module.

[0135] If the user does not perform any secondary development, they only need to connect the virtual machine operation directly to the hardware module in the virtual hardware module corresponding to the hardware module. For example, if the virtual machine needs to write to the NVMe register, the operation of the virtual NVMe module (QOM_NVMe) is to send the write operation directly to the NVMe module without any other processing.

[0136] If a user wants to modify the command execution result of the solid-state drive firmware during secondary development, the virtual NVMe module can modify the data of the write operation and send it to the NVMe module, or modify the original execution result of the virtual machine in memory and then notify the NVMe module.

[0137] Understandably, in pure SSD applications, PCIe acts as a slave device (PCIe Endpoint). The QOM of each hardware module in QEMU typically communicates directly with the physical hardware module (such as the PCIe hardware module), but custom behaviors can also be injected. For example, in secondary development, if the NVMe identifier needs to be modified, such as the NVMe protocol version number, the identifier content can be prepared in the virtual machine and submitted to the hardware module for transmission to the host. This content can then be intercepted by KVM / QEMU, allowing the user to modify the identifier content before submitting it to the hardware module for transmission to the host.

[0138] In in-memory computing applications, such as data recording or other edge computing applications, PCIe is used as the host port (root port). The PCIe hardware module is no longer in endpoint mode. An endpoint refers to a terminal that provides a human-machine interface for the host. Everyone uses the host's resources through the terminal. Therefore, QEMU's PCIeQOM and the hardware PCIe module are no longer in pass-through mode. At this time, the virtual NVMe module (QOM_NVMe) acts as a virtual device. The local Linux system can access the local Flash storage at high speed through the virtual PCIe interface, for example, by injecting NVMe commands from the virtual PCIe interface.

[0139] In Computational Storage Drive (CSD) applications, the original SSD functionality is fully retained. In this case, the PCIe module still acts as an endpoint, requiring an additional local system access path to accelerate computation on local flash data. This is achieved by adding a virtual PCIe interface to the virtual NVMe module (QOM_NVMe).

[0140] For details, please refer to [link / reference]. Figure 8 , Figure 8 This is a schematic diagram of a simulator provided in an embodiment of this application;

[0141] like Figure 8 As shown, the NVMe module corresponds to two PCIe interfaces: one from the host PCIe interface and the other from the local PCIe interface virtualized by the virtual PCIe module (QOM_PCIe).

[0142] In this embodiment of the application, a solid-state drive controller is provided, including a virtual machine for running solid-state drive firmware; and a simulator connected to the virtual machine for simulating at least one hardware module of the solid-state drive controller; wherein, when the solid-state drive firmware sends an access request to the hardware module, the virtual machine intercepts the access request and sends the access request to the simulator, so that the simulator simulates the behavior of the hardware module.

[0143] By setting up a virtual machine on the SSD controller to run the SSD firmware and setting up an emulator to simulate the hardware module of the SSD controller, the virtual machine intercepts the access request sent by the SSD firmware to the hardware module and forwards it to the emulator to simulate the behavior of the hardware module. On the one hand, by setting up a virtual machine and an emulator in the SSD controller, the software and hardware can be decoupled, and the SSD firmware can run on the virtual machine, which is conducive to the customized development of SSDs. On the other hand, it enables third parties to perform secondary development based on the emulator, improving development efficiency.

[0144] Please refer to the following: Figure 9 , Figure 9 This is a flowchart illustrating a control method for a solid-state drive controller provided in an embodiment of this application;

[0145] The control method of the solid-state drive controller is applied to the solid-state drive controller mentioned in the above embodiments. The solid-state drive controller includes a virtual machine, an emulator, and at least one hardware module.

[0146] like Figure 9 As shown, the control method of the solid-state drive controller includes the following steps:

[0147] Step S901: When the virtual processing unit executes an operation instruction, if the data page accessed by the operation instruction does not exist in memory, a page fault exception is generated;

[0148] Specifically, when the virtual processing unit executes an operation instruction, such as an I / O operation, if the data page accessed by the operation instruction does not exist in memory, for example, if the page table entry of the virtual page is 0, the virtual processing unit generates a page not found interrupt, that is, generates a page fault exception and triggers the page fault interrupt handling function.

[0149] Understandably, accessing a non-existent page will trigger a page fault exception. At this point, the solid-state drive controller's processing unit (CPU) enters a higher level of operation, such as from EL1, EL2 to EL3. This means that the operation is taken over by the host machine, and the virtual machine is suspended.

[0150] Step S902: The virtual machine intercepts the page fault and sends the page fault to the emulator;

[0151] Specifically, when the virtual machine intercepts a page fault, it handles the page fault, prepares the memory, fills the address mapping relationship into the table of the virtual machine process's memory management unit (MMU), and then returns to the virtual machine to continue running, while sending the page fault to the emulator.

[0152] Understandably, the CPU of a solid-state drive controller provides hardware support for intercepting and redirecting special instructions. Newer hardware may even provide additional resources to help software virtualize critical hardware resources, thereby improving performance. This CPU supports virtualization technology, controlling the virtualization process through a specially optimized instruction set. Using these instructions, the Virtual Machine Monitor (VMM) places the guest machine in a restricted mode; if the guest machine attempts to access physical resources, the hardware suspends the guest machine's operation, returning control to the VMM.

[0153] The virtual machine monitor can also utilize hardware virtualization enhancement mechanisms to completely redirect guest access to specific resources in restricted mode to designated virtual resources.

[0154] Understandably, the virtual machine is loaded into the kernel space on demand and runs during runtime. The virtual machine itself does not perform any device emulation.

[0155] Step S903: After the simulator receives a page fault, it simulates the behavior of the hardware module.

[0156] Specifically, page faults include memory page faults and memory-mapped page faults;

[0157] If the page fault is a memory page fault, the emulator maps the memory page to the virtual machine address to simulate the behavior of the hardware module;

[0158] If the page fault is a memory-mapped page fault, then the emulator simulates the behavior of the hardware module based on the type of operation instruction, specifically including:

[0159] If the operation instruction is a read operation, the simulator returns the read data to the virtual machine;

[0160] If the operation instruction is a write operation, the simulator will simulate the behavior of the hardware module in response to the write operation.

[0161] Specifically, simulating hardware behavior includes:

[0162] Send the operation instructions directly to the hardware module;

[0163] Alternatively, the behavior of the hardware module can be completely simulated using a simulator;

[0164] Alternatively, modify the execution results of operation instructions or hardware modules.

[0165] For example, the hardware modules to be simulated are divided into three types:

[0166] (1) Pass-through. Specifically, the simulator directly passes access requests or operation commands to the hardware module without performing any processing. In this case, the simulator acts as an intermediary.

[0167] (2) Full software simulation. Specifically, the simulator fully simulates the functions of the hardware module, enabling the simulator to fully simulate the operation of the hardware module without needing to send access requests or operation commands to the hardware module, that is, without needing to call the hardware module.

[0168] (3) Hybrid type. Specifically, the simulator modifies the access request or operation command sent to the hardware module, transmits the modified access request or operation command to the hardware module, or obtains the command execution result of the hardware module and modifies the command execution result.

[0169] Understandably, if users need to perform secondary development based on the simulator, such as modifying the command execution results of NVMe, a hybrid approach is used. If users do not need to perform secondary development, a pass-through approach is used. If users need to reuse hardware modules used by the SSD firmware, such as SPI flash, a fully software-simulated approach is used.

[0170] In one embodiment of the application, a control method for a solid-state drive controller is provided and applied to the solid-state drive controller of the above embodiment. The method includes: when the virtual processing unit executes an operation instruction, if the data page accessed by the operation instruction does not exist in memory, a page fault exception is generated; the virtual machine intercepts the page fault exception and sends it to the simulator; after receiving the page fault exception, the simulator simulates the behavior of the hardware module.

[0171] The virtual machine executes operation instructions through its virtual processing unit, intercepts page faults, and uses an emulator to simulate the behavior of hardware modules, enabling third parties to perform secondary development based on the emulator and improving development efficiency.

[0172] This application also provides a solid-state drive system; for details, please refer to [link / reference needed]. Figure 10 , Figure 10 This is a schematic diagram of the structure of a solid-state drive system provided in an embodiment of this application;

[0173] like Figure 10 As shown, the solid-state drive system 400 includes: a solid-state drive 100 and a host 200.

[0174] It should be noted that the relevant content of the solid-state drive 100 can be referred to the content mentioned in the above embodiments, and will not be repeated here.

[0175] The host 200 communicates with the solid-state drive 100. For example, the solid-state drive controller communicates with the host through a host interface processor, which handles the communication protocol with the host.

[0176] The solid-state drive controller also communicates with the host 200 through the PCIe interface. For example, in the application scenario of in-memory computing, the PCIe interface is used as a host port, and the simulator in the solid-state drive controller accesses the local flash storage at high speed through the virtual PCIe module.

[0177] This application also provides a non-volatile computer storage medium storing computer-executable instructions that are executed by one or more processors. For example, the one or more processors can execute the control method of the solid-state drive controller in any of the above method embodiments, such as executing the various steps described above.

[0178] The apparatus or device embodiments described above are merely illustrative. The unit modules described as separate components may or may not be physically separate, and the components shown as module units may or may not be physical units; that is, they may be located in one place or distributed across multiple network module units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0179] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions for a computer device (which may be a personal computer, server, or network device, etc.) to execute the various embodiments or some parts of the embodiments.

[0180] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above. For the sake of brevity, they are not provided in detail; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A solid state disk controller, characterized by, The solid state disk controller comprises: a virtual machine for running the solid state disk firmware; a simulator connected to the virtual machine for simulating at least one hardware module of the solid state disk controller; wherein when the solid state disk firmware sends an access request to the hardware module, the virtual machine intercepts the access request and sends the access request to the simulator so that the simulator simulates the behavior of the hardware module; the solid state disk controller comprises a plurality of processing units, the plurality of processing units support virtualization, and the plurality of processing units comprise a plurality of run levels; the virtual machine virtually creates a plurality of virtual processing units, and the virtual processing units are used to run the solid state disk firmware.

2. The solid state disk controller of claim 1, wherein: the solid state disk firmware corresponds to an image file; the simulator is used to load the image file to the virtual processing units so that the virtual processing units run the solid state disk firmware.

3. The solid state disk controller of claim 1, wherein: the solid state disk controller comprises a plurality of hardware modules, wherein the hardware modules comprise at least one of a PCIe module, an NVMe module, a buffer management module, an ECC module, and a flash memory management module; the simulator comprises a plurality of virtual hardware modules, each of the virtual hardware modules is used to one-to-one simulate one hardware module of the solid state disk controller, wherein the virtual hardware modules comprise at least one of a virtual PCIe module, a virtual NVMe module, a virtual buffer management module, a virtual ECC module, and a virtual flash memory management module.

4. The solid state hard disk controller of claim 3, wherein, An operation command is sent to the virtual machine through the virtual PCIe module.

5. The solid state disk controller of claim 1, wherein: the virtual machine comprises: a virtual machine monitor for intercepting an access request sent by the solid state disk firmware to the hardware module.

6. The solid state hard disk controller of claim 1, wherein, The solid state disk controller further comprises: an interrupt controller connected to the processing units of the solid state disk controller for managing and controlling maskable interrupts, priority determination of the maskable interrupts, and sending an interrupt signal to the processing units.

7. A solid state drive, comprising: The solid state disk controller of any one of claims 1-6; at least one flash memory medium in communication with the solid state disk controller. The solid state disk of claim 7; 8. A solid state disk system, characterized by, a host in communication with the solid state disk. The method applied to the solid state disk controller of any one of claims 1-6, the method comprises: when a virtual processing unit executes an operation instruction, if a data page accessed by the operation instruction does not exist in the memory, a page fault exception is generated; 9. A control method of a solid state drive controller, characterized by, the virtual machine intercepts the page fault exception and sends the page fault exception to the simulator; after the simulator receives the page fault exception, the behavior of the hardware module is simulated.

10. The method of claim 9, wherein: the page fault exception comprises a memory page fault and a memory mapping page fault; if the page fault exception is a memory page fault, the simulator maps a memory page to a virtual machine address to simulate the behavior of the hardware module. ​ ​ If the missing page exception is a memory mapping missing page, the emulator simulates the behavior of the hardware module according to the type of the operation instruction, specifically comprising: If the operation instruction is a read operation, the emulator returns read data to the virtual machine; If the operation instruction is a write operation, the emulator simulates the behavior of the hardware module generated by the write operation.

Images