Open Channel Storage Device Management Using FTL on Virtual Machines

Abstract

Embodiments of the present invention provide a system and method for accessing a storage device of a host. The method may include: receiving, by a first guest flash translation layer (FTL) instance, a first request to access a storage device from a first virtual machine running on a host, where the first request includes a first physical address of the storage device; transmitting, by the first FTL instance, the first request to a host FTL driver; converting, by the host FTL driver, the first request into a first hardware command; transmitting, by the host FTL driver, the first hardware command to a storage device; and executing, by a solid state drive, the first hardware command.

Description

Background Art

[0001] A host system having a storage device such as a solid state drive (SSD) can run multiple virtual machines. If a flash translation layer (FTL) is not implemented on the SSD, the SSD can be referred to as an open channel solid state drive. Typically, the FTL of the open channel SSD is implemented on the host system. However, an application running on the virtual machine cannot operate the memory blocks of the SSD individually through the conventional FTL on the host system. Summary of the Invention

[0002] Embodiments of the present application provide a computer-implemented method for accessing a storage device of a host. The method includes: receiving, by a first client flash translation layer (FTL) instance of a first virtual machine running on a guest operating system of the host, a first request to access the storage device from the first virtual machine, where the first request includes a first physical address of the storage device; transmitting, by the first client FTL instance, the first request to a host FTL driver of a host operating system running on the host; converting, by the host FTL driver, the first request into a first hardware command; transmitting, by the host FTL driver, the first hardware command to the storage device; and executing, by the storage device, the first hardware command to access the first physical address.

[0003] Embodiments of the present application also provide a device. The device includes: a memory for storing an instruction set; and at least one processor configured to execute the instruction set to cause the device to perform: receiving, by a first client flash translation layer (FTL) instance of a first virtual machine running on a guest operating system of the host, a first request to access the storage device from the first virtual machine, where the first request includes a first physical address of the storage device; transmitting, by the first client FTL instance, the first request to a host FTL driver of a host operating system running on the host; converting, by the host FTL driver, the first request into a first hardware command; transmitting, by the host FTL driver, the first hardware command to the storage device; and executing, by the storage device, the first hardware command to access the first physical address.

[0004] An embodiment of the present application further provides a host, including one or more non-transitory computer-readable media storing an instruction set executable by at least one processor of the host to cause the host to execute a method for accessing a storage device of the host. The method may include: receiving, via a first client flash translation layer (FTL) instance of a first virtual machine running on a guest operating system of the host, a first request to access the storage device from the first virtual machine, where the first request includes a first physical address of the storage device; transmitting the first request to a host FTL driver of a host operating system running on the host via the first client FTL instance; converting the first request into a first hardware command via the host FTL driver; transmitting the first hardware command to the storage device via the host FTL driver; and executing the first hardware command by the storage device to access the first physical address.

[0005] Additional features and advantages of the embodiments of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the embodiments of the invention. The features and advantages of the embodiments of the invention may be realized and obtained by means of the elements and combinations particularly pointed out in the appended claims.

[0006] It should be understood that the foregoing general description and the following detailed description are both exemplary and explanatory only and are not restrictive of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Embodiments and aspects of the present invention are illustrated in the following detailed description and the accompanying drawings. The various features shown in the drawings are not drawn to scale.

[0008] Figure 1A is a block diagram of an exemplary apparatus for providing virtual machine services according to some embodiments of the present application.

[0009] Figure 1B shows a schematic diagram of an exemplary cloud system according to an embodiment of the present invention.

[0010] Figure 2A shows a schematic diagram of managing an open-channel SSD on a host according to some embodiments of the present invention.

[0011] Figure 2B shows a schematic diagram of a guest FTL driver according to some embodiments of the present invention.

[0012] Figure 2C shows an exemplary request format of an IO request and a management request according to some embodiments of the present invention.

[0013] Figure 3 It is a flowchart of an exemplary process of a guest FTL instance operating on an SSD according to some embodiments of the present invention.

[0014] Figure 4 It shows an exemplary flowchart of the initialization process of a host FTL driver and a guest FTL instance according to some embodiments of the present invention.

[0015] Figure 5 It is a flowchart of a method for a computing implementation of accessing a solid-state drive of a host according to some embodiments of the present invention. Detailed Description of the Invention

[0016] Specific aspects of the present invention will be described in more detail below. If there is a conflict with the terms or definitions cited, the terms and definitions provided herein shall prevail. The term "example" means "instance", rather than "model".

[0017] A virtual machine is an emulation of a computer system, which can provide the functions of a physical computer. Different from traditional designs, in the embodiments of the present application, the virtual machine is equipped with a guest flash translation layer (FTL) instance for sending requests associated with the physical addresses of the storage devices of the host (e.g., solid-state drives (SSDs)), and the host equipped with one or more virtual machines is equipped with a host FTL driver for verifying and processing the requests. Therefore, the virtual machine according to the embodiments of the present application can directly operate on the physical addresses of the storage devices (e.g., SSDs) of the host, and at the same time, the host FTL driver can ensure the data security of each virtual machine.

[0018] The guest FTL instance can map the logical block address (LBA) on the host side (e.g., the sector number of the SSD) to the physical block address (PBA) of the flash memory. This process can also be referred to as LBA2PBA mapping. To implement the FTL function in a virtual machine, the device providing virtual machine services can be as follows.

[0019] Figure 1A It is a block diagram of an exemplary device 100 for providing virtual machine services according to some embodiments of the present application. As Figure 1A shown, the device 100 may include a processor 102, a memory 104, a network interface 106, a peripheral interface 108, and a bus 110.

[0020] When the processor 102 executes the instructions and methods described herein, the apparatus 100 can become a dedicated machine for providing virtual machine services. The processor 102 can be any type of circuit capable of manipulating or processing information. For example, the processor 102 can include any number of central processing units (or "CPUs"), graphics processing units (or "GPUs"), neural processing units ("NPUs"), microcontroller units ("MCUs"), optical processors, programmable logic controllers, microcontrollers, microprocessors, digital signal processors, intellectual property (IP) cores, programmable logic arrays (PLAs), programmable array logic (PALs), generic array logic (GALs), complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs), system on a chip (SoC), application specific integrated circuits (ASICs), etc. In some embodiments, the processor 102 can also be a group of processors grouped as a single logical component. For example, as Figure 1A shown, the processor 102 can include a multiprocessor, including processors 102a, 102b, and 102n.

[0021] The memory 104 can be configured to store data (e.g., a set of instructions, computer code, intermediate data, etc.). For example, as Figure 1A shown, the stored data can include program instructions (e.g., program instructions for implementing the steps of a method for processing video content) and data for processing (e.g., a video sequence, a video bitstream, or a video stream). The processor 102 can access the program instructions and the data for processing (e.g., via the bus 110), and execute the program instructions to perform operations or processing on the data for processing. The memory 104 can include high-speed random access storage devices or non-volatile storage devices. In some embodiments, the memory 104 can include any number of random access memories (RAMs), read-only memories (ROMs), optical discs, magnetic disks, hard disk drives, solid state drives (SSDs), flash drives, secure digital (SD) cards, memory sticks, compact flash (CF) cards, etc. The memory 104 can also be a group of memories grouped as a single logical component ( Figure 1A not shown in the figure).

[0022] The bus 110 can be a communication device for transmitting data between components inside the apparatus 100, such as an internal bus (e.g., a CPU-memory bus), an external bus (e.g., a universal serial bus port, a peripheral component interconnect express port), or the like.

[0023] For the sake of explanation without ambiguity, in the present invention, the processor 102 and other data processing circuits may be collectively referred to as "data processing circuits". The data processing circuits may be implemented entirely as hardware, or as a combination of software, hardware, or firmware. In addition, the data processing circuits may be a single independent module, or may be fully or partially integrated into any other component of the device 100.

[0024] The device 100 may further include a network interface 106 to provide wired or wireless communication with a network (e.g., the Internet, an intranet, a local area network, a mobile communication network, etc.). In some embodiments, the network interface 106 may include any combination of any number of network interface controllers (NICs), radio frequency (RF) modules, repeaters, transceivers, modems, routers, gateways, wired network adapters, wireless network adapters, Bluetooth adapters, infrared adapters, near field communication ("NFC") adapters, cellular network chips, etc.

[0025] In some embodiments, optionally, the device 100 may further include a peripheral interface 108 to provide connections to one or more peripheral devices. As Figure 1A shown, the peripheral devices may include, but are not limited to, cursor control devices (e.g., a mouse, a touchpad, or a touch screen), a keyboard, a display (e.g., a cathode ray tube display, a liquid crystal display, or a light emitting diode display), a video input device (e.g., a camera or an input interface coupled to a video archive), etc.

[0026] Figure 1B A schematic diagram of an exemplary cloud system 130 including the device 100 according to an embodiment of the present invention is shown.

[0027] As Figure 1B shown, the cloud system 130 may provide virtual machine services to multiple clients (e.g., elements 142 - 148), and may include multiple computing servers (e.g., elements 132 and 134). The multiple computing servers may be physically or virtually grouped in one or more networks, which together form the cloud system 130. The one or more networks may be private, public, community, or a combination thereof. In some embodiments, the computing server 132 or 134 may be, for example Figure 1A the device 100. For simplicity and clarity, Figure 1B the device 100 is shown in a simplified manner. The multiple clients may include a tablet computer 142, a laptop computer 144, a desktop computer 146, a mobile phone 148, etc. The computing servers 132 and 134 may be referred to as remote machines or hosts, while the multiple clients 142 - 148 may be referred to as local machines or clients.

[0028] In some embodiments, a remote machine (e.g., 132 or 134) can execute a virtual machine to provide an execution session in which virtual applications are implemented on behalf of a user of a local machine (e.g., 144). Notably, the cloud system 130 including the remote machines 132 and 134 can execute multiple virtual machines, and these virtual machines can run on one or more local machines.

[0029] The virtual machine runs on a host operating system that runs on the remote machine, and the virtual machine also runs a guest operating system (OS). The guest operating system can provide process control, memory management, and other services required by the virtual applications. In some embodiments of the present invention, the guest OS may further include a guest flash translation layer (FTL) driver, and the host OS may further include a host FTL driver. The guest FTL driver and the host FTL driver can be used to manage the direct operation of the virtual machine on the open-channel SSDs of the cloud system 130.

[0030] Figure 2A A schematic diagram of managing an open-channel SSD on a host 200 according to some embodiments of the present invention is shown.

[0031] The host 200 can be implemented by, for example, the device 100 described Figure 1A The underlying hardware 2000 of the host 200 running the host operating system (OS) 2100 can include open-channel SSDs 202 and 204. Notably, the underlying hardware 2000 also includes components such as a processor, a network interface, a peripheral interface, and a bus, the detailed description of which can be found in Figure 1A .

[0032] The open-channel SSDs 202 and 204 present a set of channels to the host OS 2100, and each channel contains a plurality of parallel units (PUs). For example, as Figure 2A shown, the SSD 202 can include a PU group 2022 and a PU group 2024, and the SSD 204 can include a PU group 2042. One PU can cover one or more physical modules of the open-channel SSD, and one module can only be a member of one PU. Each PU can process a single I / O request at a time.

[0033] The host OS 2100 may include a host Flash Translation Layer (FTL) driver 2102. The host FTL driver 2102 may be configured to convert client FTL requests of a client FTL instance into hardware commands executable by the SSD (e.g., 202 or 204), and convert hardware signals (e.g., post-completion signals) into guest responses. The host FTL driver 2102 may also be configured to determine whether the physical address associated with the client FTL request is accessible by the virtual machine running the client FTL instance. Notably, the host OS 2100 may also include an interface for communicating with the guest OS 2200, and the host FTL driver 2102 may include a protocol (e.g., FTL protocol) for communicating with the guest OS 2200. Additionally, the host OS 2100 may create a queue (e.g., 206a - 206c) for storing hardware commands executable by the SSD.

[0034] The guest OS 2200 may include one or more virtual machines 2202 - 2206 and a guest FTL driver (to be discussed with reference to Figure 2B ). The guest FTL driver may be implemented using a virtual I / O framework (e.g., Virtio). The virtual I / O framework may virtualize the interfaces of components of the virtual machine, such as the virtual SSD of the virtual machine, and cooperate with the host OS 2100 to allow the virtual machines of the guest OS 2200 to access resources in the host. In some embodiments, the guest FTL driver may be instantiated as a guest FTL instance for each virtual machine. For example, virtual machines 2202 - 2206 may respectively include guest FTL instances 2208 - 2212. Notably, each virtual machine may include a virtual interface for communicating with the host OS 2100 and receiving instructions from the user of the virtual machine. Additionally, the guest OS 2200 also creates virtual queues (e.g., 208a, 208b, or 208c) for the virtual machines. The virtual queues may store requests for accessing the SSD, which may be further retrieved by the host FTL driver 2102.

[0035] Figure 2B A schematic diagram of a guest FTL driver 210 according to some embodiments of the present invention is shown.

[0036] As Figure 2B shown, the guest FTL driver 210 may include at least one input / output (I / O) unit 212, a logical block address to physical block address (LBA2PBA) mapping unit 214, a garbage collection unit 216, a media management unit 218, an error handling unit 220, and a virtual queue 222.

[0037] The input / output unit 212 can be a virtual interface for communicating information (e.g., physical addresses associated with requests to access the SSD) with the guest OS and the host OS. For example, when a user of a virtual machine issues a request to access the SSD, the physical address associated with the request can be passed through the input / output unit 212 to the guest FTL driver 210.

[0038] In some embodiments, the guest FTL driver 210 can provide two types of requests, including IO requests and management requests. Figure 2C An exemplary request format for IO requests and management requests according to some embodiments of the present invention is shown. The IO request can be for a read operation to read data from an address of the SSD, a write operation to write data to an address of the SSD, or an erase operation to erase data from an address of the SSD. As Figure 2C shown, the IO request can include an opcode field for indicating the operation type (e.g., read, write, or erase), a physical start address field, a data buffer field for storing memory data, and a data buffer length field for indicating the length of the data buffer. The management request can point to management operations, such as geometry operations, bad block table operations, identification operations, format operations, etc. As Figure 2C shown, the management request can include an opcode field for indicating the operation type, a data buffer field for storing memory data, and a data buffer length field for indicating the length of the data buffer.

[0039] The LBA2PBA mapping unit 214 can be configured to map the logical address associated with a request (e.g., an IO request or a management request) to the physical address of the SSD, so that the virtual machine can directly access a plurality of PUs of the SSD.

[0040] The garbage collection unit 216 can be configured to systematically identify pages containing unwanted data (e.g., erased data, modified data, etc.), and clear the unwanted data blocks during off-peak hours to maintain the best write speed during normal operation.

[0041] The media management unit 218 can be configured to monitor the number of times the SSD pages / blocks have been read / written, and balance the read / write times across the SSD pages / blocks. The media management unit 218 can also identify errors in the SSD pages / blocks, and invite the error handling unit 220 to handle the SSD pages / blocks.

[0042] The error handling unit 220 can be configured to repair or regenerate the metadata stored in the SSD pages / blocks, and record error reports.

[0043] The virtual queue 222 (also see Figure 2AThe queues 208a, 208b, or 208c) can be configured to store customer FTL requests in sequence. In some embodiments, the virtual queue 222 can be implemented by a memory space accessible to both the customer FTL instance and the host FTL driver, such that the data stored in the virtual queue 222 (e.g., customer FTL requests or post-hardware completion signals) can be accessed and retrieved by the customer FTL instance and the host FTL driver. In other words, the communication between the customer FTL instance and the host FTL driver is achieved through the virtual queue 222.

[0044] Figure 3 is a flowchart of an exemplary process 300 for a customer FTL instance operating on an SSD according to some embodiments of the present invention. As Figure 3 shown, the process 300 may include the following steps.

[0045] In step 302, a customer FTL instance (e.g., the customer FTL instance 2208 in FIG. 2) may send a customer FTL request for accessing the SSD to a virtual queue (e.g., the virtual queue 222). It can be understood that the customer FTL request can be received from a virtual machine running on the host. For example, an application in the virtual machine may generate an instruction related to a logical address and send the instruction to the customer FTL instance. As described above, the logical address associated with the instruction can be mapped to a physical address in the SSD using, for example, the LBA2PBA mapping unit 214 of the customer FTL instance. Thus, when the customer FTL instance sends a customer FTL request to the virtual queue, the customer FTL request contains the physical address in the SSD.

[0046] In step 304, the host FTL driver (e.g., the host FTL driver 2102 in FIG. 2) may obtain the customer FTL request from the virtual queue and convert the customer FTL request into a hardware command executable by the SSD. In some embodiments, the customer FTL request is presented in a format different from the hardware command and may be "translated" into a hardware command before being executed. In some embodiments, the guest FTL request may contain an instruction executable by the SSD, and the host FTL driver may forward the instruction as a hardware command.

[0047] As described above, the virtual queue is accessible to the customer FTL instance and the host FTL driver. Therefore, the customer FTL request can be passed to the host FTL driver through the virtual queue.

[0048] The virtual machine is only allowed to access a given range of physical addresses, which can ensure the data security of each virtual machine. Therefore, in some embodiments, the host FTL driver can also parse the guest FTL requests of the virtual machine and determine whether the guest FTL request is associated with the accessible physical address range. If the host FTL driver determines that the guest FTL request is associated with an address outside the accessible range, the host FTL driver can send an error signal back to the virtual queue.

[0049] In step 306, the host FTL driver can send the hardware command to the hardware queue. The hardware queue is implemented in the memory of the host and is used to store one or more hardware commands. It can be understood that only the hardware commands associated with the addresses within the accessible range can be sent to the hardware queue.

[0050] In step 308, the SSD can obtain the hardware command from the hardware queue and execute the hardware command, so as to operate on the parallel unit of the SSD as required by the guest FTL instance.

[0051] In step 310, the SSD can send a signal indicating that the SSD operation is completed to the hardware queue. Similar to obtaining the hardware command from the hardware queue, in step 312, the host FTL driver can obtain the signal indicating that the operation is completed and convert it into a guest response.

[0052] In step 314, the host FTL driver can send the guest response to the virtual queue. Then, in step 316, the guest FTL instance can obtain the guest response from the virtual queue. After receiving the guest response, the guest FTL instance can know that its SSD operation request has been completed.

[0053] Figure 4 An exemplary flowchart of the initialization process 400 of the host FTL driver and the guest FTL instance according to some embodiments of the present invention is shown.

[0054] Initialization 400 may include a host FTL driver initialization process executed on the host OS side and a guest FTL instance initialization process executed on the guest OS side. The host FTL driver initialization process and the guest FTL instance initialization process can be executed sequentially or in parallel.

[0055] As Figure 4 shown, the host FTL driver initialization process can be executed by the host OS, and it may include the following steps.

[0056] In step 402, the host FTL driver can be started on the host OS. Then, in step 404, a hardware queue for the open-channel SSD can be created to receive hardware commands. A hardware queue can be associated with a plurality of parallel units (PUs), such that hardware commands from one hardware queue can only be applied to the plurality of PUs corresponding to that hardware queue.

[0057] The customer FTL instance initialization process can be executed by the customer OS and can include the following steps.

[0058] In step 406, the host FTL driver can be started in the customer OS.

[0059] Then, in step 408, a virtual open-channel SSD and a virtual queue can be created for the virtual machine running on the customer OS. It can be understood that the virtual queue can correspond to the hardware queue created in step 404, and each virtual queue and the hardware queue corresponding to that virtual queue can be associated with a set of parallel units (PUs) of the open-channel SSD. If a virtual queue or a hardware queue is not associated with a certain set of PUs, requests or instructions in the virtual queue or the hardware queue cannot be executed to access that set of PUs.

[0060] In step 410, the customer FTL instance can be initialized. The host FTL driver can be instantiated to create one or more customer FTL instances. Each customer FTL instance can be associated with a virtual queue, which corresponds to a plurality of PUs through the corresponding hardware queue. Therefore, each customer FTL instance can only be associated with a plurality of PUs through the corresponding virtual queue and hardware queue. In other words, a virtual machine can only operate on a plurality of PUs corresponding to the customer FTL instance of that virtual machine. To avoid any possible data security vulnerabilities, there are no common PUs among the plurality of sets of PUs corresponding to each customer FTL instance.

[0061] In step 412, requests from the application running on the virtual machine can be processed. The process of processing requests has been described with reference to Figure 3 and will not be elaborated here.

[0062] Since the customer FTL instance can convert logical addresses into physical addresses within the virtual machine, by running the customer FTL instance on the virtual machine, the virtual machine can perform direct operations on the PUs of the host's SSD. At the same time, since a virtual machine is only allowed to run on a plurality of PUs, virtual machine operation isolation and data security can be guaranteed.

[0063] Figure 5is a flowchart of a computing implementation method 500 for accessing a host's solid-state drive (SSD) according to some embodiments of the present invention. Method 500 can be implemented by, for example, Figure 1A a device 100 operating as a host (e.g., Figure 2A host 200). The host can run a host operating system (OS) and a guest operating system OS. Method 500 can include the following steps.

[0064] In step 502, a first guest flash translation layer (FTL) instance can receive a first request for accessing the solid-state drive, and the first request is from a first virtual machine running on the host. As described above, the first guest FTL instance can be generated by instantiating a guest FTL driver. The first request can be related to an application running on a first virtual machine of the guest operating system. For example, an application running on the first virtual machine can issue an instruction to access a logical address, and the first guest FTL instance can map the logical address to a physical address on the SSD using, for example, Figure 2B an LBA2PBA mapping unit 214.

[0065] In some embodiments, the first request can include an input / output (IO) request or a management request. As discussed with reference to Figure 2C the IO request can include a first opcode field, a starting physical address field, a first data buffer field, and a first data buffer length field. And the management request can include a second opcode field, a second data buffer field, and a second data buffer length field. Thus, the first request can include a first physical address of the SSD.

[0066] Therefore, the IO request is associated with a read command, a write command, or an erase command, and the management request is associated with a geometry command, a bad block table command, an identification command, or a format command.

[0067] In some embodiments, since the guest OS can run multiple virtual machines, a second guest FTL instance can also be generated for another virtual machine by instantiating the guest FTL driver. Thus, a second request for accessing the solid-state drive can be received from a second virtual machine running on the host. Similarly, the second request can include a second physical address of the SSD.

[0068] In step 504, the first FTL instance can transmit the first request to a host FTL driver. The host FTL driver can run on the host operating system.

[0069] In some embodiments, the guest OS may include a first guest queue for storing a first request (e.g., the virtual queue 222 of FIG. 2) and a second guest queue for storing a second request. The host FTL driver may also access the first and second guest queues. Thus, by fetching guest requests (e.g., the first guest request or the second guest request) from the corresponding guest queues, the host FTL driver of the host OS may receive the guest requests from the guest FTL instance of the guest OS.

[0070] In step 506, the host FTL driver may convert the first request into a first hardware command. Similarly, the host FTL driver may also convert the second request into a second hardware command.

[0071] In step 508, the host FTL driver may transmit the first hardware command to the solid state drive. Similarly, the second hardware command may also be transmitted to the solid state drive.

[0072] In some embodiments, the solid state drive may include a first host queue for storing the first hardware command and a second host queue for storing the second hardware command. Both the host FTL driver and the solid state drive may access the first host queue and the second host queue, so that the solid state drive may fetch instructions from the host FTL driver for execution.

[0073] In step 510, the solid state drive may execute the first hardware command and the second hardware command. As described above, each guest FTL instance can only be associated with a plurality of parallel units (PUs) through the corresponding virtual queue and hardware queue. Thus, the solid state drive may operate on a first plurality of PUs according to the first hardware command and operate on a second plurality of PUs according to the second hardware command, and there is no common PU between the first plurality of PUs and the second plurality of PUs. A first physical address may point to one or more PUs of the first plurality of PUs, and a second physical address may point to one or more PUs of the second plurality of PUs. As described above, the first plurality of PUs can only be accessed by the first virtual machine, and the second plurality of PUs can only be accessed by the second virtual machine, thereby isolating the data of the first virtual machine and the second virtual machine from each other.

[0074] After executing the hardware commands corresponding to the requests for accessing the solid state drive, the solid state drive may send a completion signal to the host FTL driver. For example, refer to Figure 3As discussed, the completion signal can also be placed in the corresponding hardware queue so that the host FTL driver can obtain the completion signal. Then, the host FTL driver can convert the completion signal into a client response to the client FTL instance. In some embodiments, the host FTL driver can place the client response in the corresponding client queue and use the corresponding client queue to transmit the client response to the client FTL instance.

[0075] In some embodiments, method 500 may further include an initialization phase before step 502. For example, as Figure 4 discussed, the initialization phase may include starting the host FTL driver on the host operating system; creating a second queue on the solid state drive; starting the client FTL driver for the virtual machine on the client operating system; creating a virtual SSD and a first queue; and initializing the first FTL instance using the client FTL driver.

[0076] Embodiments of the present invention also provide a computer program product. The computer program product may include a non-transitory computer-readable storage medium having computer-readable program instructions thereon for causing a processor to execute the above method.

[0077] The computer-readable storage medium can be a tangible device that can store instructions for use by an instruction execution device. The computer-readable storage medium can be, for example but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples of the computer-readable storage medium include: a portable computer floppy disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punched card or raised structures in grooves having instructions recorded thereon, and any suitable combination of the foregoing.

[0078] The computer-readable program instructions for performing the above method may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state-setting data, or any combination of source code or object code written in one or more programming languages, including object-oriented programming languages and traditional procedural programming languages. The computer-readable program instructions may be executed entirely on a computer system as a stand-alone software package, or partially on a first computer and partially on a second computer remotely connected to the first computer. In the latter case, the second remote computer may be connected to the first computer through any type of network connection, including a local area network (LAN) or a wide area network (WAN).

[0079] The computer-readable program instructions may be provided to a processor of the computer or other programmable data processing device to generate a machine such that the instructions executed via the processor of the computer or other programmable data processing device create a means for implementing the above method.

[0080] The embodiments may be further described using the following clauses:

[0081] 1. A computer-implemented method for accessing a storage device of a host, comprising:

[0082] Receiving, by a first client flash translation layer (FTL) instance of a first virtual machine running on a guest operating system of the host, a first request to access the storage device from the first virtual machine, wherein the first request includes a first physical address of the storage device;

[0083] Transmitting, by the first client FTL instance, the first request to a host FTL driver of a host operating system running on the host;

[0084] Converting, by the host FTL driver, the first request into a first hardware command;

[0085] Transmitting, by the host FTL driver, the first hardware command to the storage device; and

[0086] Executing, by the storage device, the first hardware command to access the first physical address.

[0087] 2. The method according to clause 1, further comprising:

[0088] Receiving, by a second client FTL instance, a second request to access the storage device from a second virtual machine running on the host; and

[0089] Convert the second request into a second hardware command through the host FTL driver, where the second request includes a second physical address of the storage device.

[0090] 3. The method according to clause 2, further comprising:

[0091] Operating a first set of a plurality of parallel units (PUs) according to the first hardware command; and

[0092] Operating a second set of a plurality of PUs according to the second hardware command, where there are no common PUs between the first set of a plurality of PUs and the second set of a plurality of PUs.

[0093] 4. The method according to clause 3, where the first set of a plurality of PUs can only be accessed by the first virtual machine, and the second set of a plurality of PUs can only be accessed by the second virtual machine.

[0094] 5. The method according to any one of clauses 2-4, where

[0095] The guest operating system includes a first guest queue for storing the first request and a second guest queue for storing the second request, and the first guest queue and the second guest queue can be accessed by the host FTL driver; and

[0096] The storage device includes a first host queue for storing the first hardware command and a second host queue for storing the second hardware command, and the first host queue and the second host queue can be accessed by the host FTL driver and the storage device.

[0097] 6. The method according to any one of clauses 1-5, further comprising:

[0098] Transmit a completion signal to the host FTL driver through the storage device;

[0099] Convert the completion signal into a guest response for the guest FTL instance through the host FTL driver; and

[0100] Transmit the guest response to the guest FTL instance through the host FTL driver.

[0101] 7. The method according to any one of clauses 1-6, where the first request includes an input / output (IO) request or a management request.

[0102] 8. The method according to clause 7, where

[0103] The IO request includes a first opcode field, a starting physical address field, a first data buffer field, and a first data buffer length field; and

[0104] The management request includes a second opcode field, a second data buffer field, and a second data buffer length field.

[0105] 9. The method according to clause 7 or 8, wherein

[0106] The IO request is associated with a read command, a write command, or an erase command, and

[0107] The management request is associated with a geometry command, a bad block table command, an identification command, or a format command.

[0108] 10. The method according to any one of clauses 5 - 9, further comprising:

[0109] Starting the host FTL driver on the host operating system;

[0110] Creating a second queue on the storage device;

[0111] Starting a guest FTL driver on the guest operating system;

[0112] Creating a virtual storage device and a first queue; and

[0113] Initializing the first FTL instance using the guest FTL driver.

[0114] 11. An apparatus, comprising:

[0115] A memory for storing an instruction set; and

[0116] At least one processor configured to execute the instruction set to cause the apparatus to perform:

[0117] Receiving, via a first guest flash translation layer (FTL) instance of a first virtual machine running on a guest operating system of the host, a first request to access the storage device, wherein the first request includes a first physical address of the storage device;

[0118] Transmitting, via the first guest FTL instance, the first request to a host FTL driver of a host operating system running on the host;

[0119] Converting, via the host FTL driver, the first request into a first hardware command;

[0120] Transmitting, via the host FTL driver, the first hardware command to the storage device; and

[0121] Execute the first hardware command via the storage device to access the first physical address.

[0122] 12. The apparatus according to clause 11, wherein the at least one processor is configured to execute the instruction set such that the apparatus further performs:

[0123] Receive a second request for accessing the storage device from a second virtual machine running on the host via a second guest FTL instance; and

[0124] Convert the second request into a second hardware command via the host FTL driver, wherein the second request includes a second physical address of the storage device.

[0125] 13. The apparatus according to clause 12, wherein the at least one processor is configured to execute the instruction set such that the apparatus further performs:

[0126] Operate a first set of plural parallel units (PUs) associated with the first physical address according to the first hardware command; and

[0127] Operate a second set of plural PUs associated with the second physical address according to the second hardware command, wherein there is no common PU between the first set of plural PUs and the second set of plural PUs.

[0128] 14. The apparatus according to clause 13, wherein the first set of plural PUs is only accessible by the first virtual machine, and the second set of plural PUs is only accessible by the second virtual machine.

[0129] 15. The apparatus according to any one of clauses 12 - 14, wherein

[0130] The guest operating system includes a first guest queue for storing the first request and a second guest queue for storing the second request, and the first guest queue and the second guest queue are accessible by the host FTL driver; and

[0131] The storage device includes a first host queue for storing the first hardware command and a second host queue for storing the second hardware command, and the first host queue and the second host queue are accessible by the host FTL driver and the storage device.

[0132] 16. The apparatus according to any one of clauses 11 - 15, wherein the at least one processor is configured to execute the instruction set such that the apparatus further performs:

[0133] Transmit a completion signal to the host FTL driver through the storage device;

[0134] Convert the completion signal into a client response for the client FTL instance through the host FTL driver; and

[0135] Transmit the client response to the client FTL instance through the host FTL driver.

[0136] 17. The device according to any one of clauses 11 - 16, wherein the first request includes an input / output (IO) request or an administrative request.

[0137] 18. The device according to clause 17, wherein

[0138] The IO request includes a first opcode field, a starting physical address field, a first data buffer field, and a first data buffer length field; and

[0139] The administrative request includes a second opcode field, a second data buffer field, and a second data buffer length field.

[0140] 19. The device according to clause 17 or 18, wherein

[0141] The IO request is associated with a read command, a write command, or an erase command, and

[0142] The administrative request is associated with a geometry command, a bad block table command, an identification command, or a format command.

[0143] 20. A host, comprising one or more non - transitory computer - readable media storing an instruction set executable by at least one processor of the host to cause the host to perform a method for accessing a storage device of the host, the method may include:

[0144] Receive a first request to access the storage device from a first client flash translation layer (FTL) instance of a first virtual machine running on a guest operating system of the host, wherein the first request includes a first physical address of the storage device;

[0145] Transmit the first request to a host FTL driver of a host operating system running on the host through the first client FTL instance;

[0146] Convert the first request into a first hardware command through the host FTL driver;

[0147] Transmit the first hardware command to the storage device through the host FTL driver; and

[0148] Execute the first hardware command to access the first physical address through the storage device.

[0149] The flowcharts and diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of the possible implementations of devices, methods, and computer program products according to various embodiments of the present specification. In this regard, a box in a flowchart or diagram can represent a part of a software program, segment, or code that includes one or more executable instructions for implementing a particular function. It should also be noted that in some alternative implementations, the functions marked in the boxes may not occur in the order marked in the drawings. For example, depending on the functions involved, two consecutive boxes shown may actually be executed substantially simultaneously, or sometimes the boxes may be executed in the reverse order. It should also be noted that each box of the diagrams and / or flowcharts, as well as combinations of boxes in the diagrams and flowcharts, can be implemented by a system based on dedicated hardware that performs the specified functions or actions, or by a combination of dedicated hardware and computer instructions.

[0150] It should be understood that, for the sake of clarity, certain features of the specification described in the context of separate embodiments may also be provided in combination in a single embodiment. Conversely, for the sake of brevity, the various features of the specification described in the context of a single embodiment may also be provided separately, or in any suitable sub-combination, or appropriately in any other described embodiment of the specification. Certain features described in the context of various embodiments are not considered to be essential features of those embodiments unless the embodiments are inoperable without these elements.

[0151] Although the present specification has been described in connection with specific embodiments, it is apparent that many alternatives, modifications, and variations will be obvious to those skilled in the art. For example, although some embodiments are described using the flow-charting of an input data matrix as an example, the described systems and methods can be applied to any parallel computing task. Accordingly, it is intended to cover all such alternatives, modifications, and variations that fall within the spirit and broad scope of the appended claims.

Claims

1. A computer-implemented method for accessing a storage device of a host, comprising: receiving, by a first client flash translation layer (FTL) instance of a first virtual machine running on a guest operating system of the host, a first request to access the storage device from the first virtual machine, wherein the first request includes a first physical address of the storage device; transmitting, by the first client FTL instance, the first request to a host FTL driver of a host operating system running on the host; converting, by the host FTL driver, the first request into a first hardware command; transmitting, by the host FTL driver, the first hardware command to the storage device; and executing, by the storage device, the first hardware command to access the first physical address; wherein a second request for accessing the storage device is received from a second virtual machine running on the host by a second client FTL instance; and converting, by the host FTL driver, the second request into a second hardware command, wherein the second request includes a second physical address of the storage device.

2. The method according to claim 1, further comprising: operating a first set of a plurality of parallel units (PUs) according to the first hardware command; and operating a second set of a plurality of PUs according to the second hardware command, wherein there is no common PU between the first set of a plurality of PUs and the second set of a plurality of PUs.

3. The method according to claim 2, wherein the first set of a plurality of PUs can only be accessed by the first virtual machine, and the second set of a plurality of PUs can only be accessed by the second virtual machine.

4. The method according to claim 1, wherein the guest operating system includes a first guest queue for storing the first request and a second guest queue for storing the second request, and the first guest queue and the second guest queue are accessible by the host FTL driver; and the storage device includes a first host queue for storing the first hardware command and a second host queue for storing the second hardware command, and the first host queue and the second host queue are accessible by the host FTL driver and the storage device.

5. The method according to claim 1, further comprising: transmitting, by the storage device, a post-completion signal to the host FTL driver; converting, by the host FTL driver, the post-completion signal into a guest response for the client FTL instance; and transmitting, by the host FTL driver, the guest response to the client FTL instance.

6. The method according to claim 1, wherein the first request includes an input / output (IO) request or a management request.

7. The method according to claim 6, wherein the IO request includes a first opcode field, a starting physical address field, a first data buffer field, and a first data buffer length field; and the management request includes a second opcode field, a second data buffer field, and a second data buffer length field.

8. The method according to claim 6, wherein, the IO request is associated with a read command, a write command or an erase command, and the management request is associated with a geometry command, a bad block table command, an identification command or a format command.

9. The method according to claim 4, further comprising: starting the host FTL driver on the host operating system; creating a second queue on the storage device; starting a client FTL driver on the guest operating system; creating a virtual storage device and a first queue; and initializing the first client FTL instance using the client FTL driver.

10. An apparatus, comprising: a memory for storing an instruction set; and at least one processor configured to execute the instruction set to cause the apparatus to perform: receiving, via a first client flash translation layer (FTL) instance of a first virtual machine running on a guest operating system of a host, a first request to access a storage device, wherein the first request includes a first physical address of the storage device; transmitting, via the first client FTL instance, the first request to a host FTL driver of a host operating system running on the host; converting, via the host FTL driver, the first request into a first hardware command; transmitting, via the host FTL driver, the first hardware command to the storage device; and executing, via the storage device, the first hardware command to access the first physical address; wherein a second request for accessing the storage device is received, via a second client FTL instance, from a second virtual machine running on the host; and converting, via the host FTL driver, the second request into a second hardware command, wherein the second request includes a second physical address of the storage device.

11. The apparatus according to claim 10, wherein, the at least one processor is configured to execute the instruction set to cause the apparatus to further perform: operating, according to the first hardware command, a first set of a plurality of parallel units (PUs) associated with the first physical address; and operating, according to the second hardware command, a second set of a plurality of PUs associated with the second physical address, wherein there is no common PU between the first set of a plurality of PUs and the second set of a plurality of PUs.

12. The apparatus according to claim 11, wherein, the first set of a plurality of PUs is only accessible by the first virtual machine, and the second set of a plurality of PUs is only accessible by the second virtual machine.

13. The apparatus according to claim 10, wherein, the guest operating system includes a first client queue for storing the first request and a second client queue for storing the second request, and the first client queue and the second client queue are accessible by the host FTL driver; and the storage device includes a first host queue for storing the first hardware command and a second host queue for storing the second hardware command, and the first host queue and the second host queue are accessible by the host FTL driver and the storage device.

14. The apparatus according to claim 10, wherein, the at least one processor is configured to execute the instruction set to cause the apparatus to further perform: transmit a completion signal to the host FTL driver through the storage device; convert the completion signal into a client response for the client FTL instance through the host FTL driver; and transmit the client response to the client FTL instance through the host FTL driver.

15. The apparatus according to claim 10, wherein, the first request includes an input / output IO request or an administrative request.

16. The apparatus according to claim 15, wherein, the IO request includes a first opcode field, a starting physical address field, a first data buffer field, and a first data buffer length field; and the administrative request includes a second opcode field, a second data buffer field, and a second data buffer length field.

17. The apparatus according to claim 15, wherein, the IO request is associated with a read command, a write command, or an erase command, and the administrative request is associated with a geometry command, a bad block table command, an identification command, or a format command.

18. A host including one or more non-transitory computer-readable media storing an instruction set executable by at least one processor of the host to cause the host to perform a method for accessing a storage device of the host, the method comprising: receiving, from a first client flash translation layer (FTL) instance of a first virtual machine running on a guest operating system of the host, a first request to access the storage device, wherein the first request includes a first physical address of the storage device; transmitting the first request to a host FTL driver of a host operating system running on the host through the first client FTL instance; converting the first request into a first hardware command through the host FTL driver; transmitting the first hardware command to the storage device through the host FTL driver; and executing the first hardware command to access the first physical address through a solid state drive; wherein a second request for accessing the storage device is received from a second virtual machine running on the host through a second client FTL instance; and converting the second request into a second hardware command through the host FTL driver, wherein the second request includes a second physical address of the storage device.

Images