Managed nand flash memory zone control against a durable hacker

Abstract

This application relates to managed NAND flash memory zone control against durability hackers. The disclosed embodiments are directed to improving the lifetime of a memory device. In one embodiment, a system is disclosed that includes a host processor and a memory device, where the host processor is configured to receive a write command from a virtual machine, identify a zone identifier associated with the virtual machine, augment the write command with the zone identifier, and issue the write command to the memory device, and the memory device is configured to receive the write command, identify a zone that includes a subset of addresses that can be written to by the memory device using a zone configuration table, and write data to an address in the subset of addresses.

Description

Technical Field

[0001] At least some of the embodiments disclosed herein relate generally to semiconductor devices, and more specifically, to improving the security of flash memory devices. Background Technology

[0002] Flash memory devices store data in an array of cells, each cell comprising one or more transistor elements that store the charge of bits representing the data. The fundamental physical characteristics of transistors allow each cell to support a fixed number or range of operations that affect the cell's contents. The number of times a memory cell can be programmed or erased before a failure occurs is called the memory cell's endurance.

[0003] To improve the lifespan of flash memory devices, these devices typically utilize wear leveling to “extend” the program / erase (P / E) cycle across all cells. Specifically, wear leveling routines, implemented by the flash memory controller, arrange data so that erases and rewrites are evenly distributed across memory cells. The controller implements this rearrangement by distributing physical block address (PBA) values ​​assigned to logical block address (LBA) values. Therefore, each memory cell is theoretically programmed and erased evenly, and no single cell fails faster than another.

[0004] Despite the use of wear leveling routines, memory devices such as NAND flash memory can still suffer accelerated durability failures due to malicious or bad write software that rapidly “drains” the P / E cycles of the memory array. Summary of the Invention

[0005] In one aspect, this application provides a system including a host processor and a memory device, wherein the host processor is configured to receive a write command from a virtual machine, identify a zone identifier associated with the virtual machine, amplify the write command with the zone identifier, and issue a write command to the memory device, and the memory device is configured to receive the write command, identify a zone including a subset of addresses writable by the memory device using a zone configuration table, and write data to an address in the subset of addresses.

[0006] In another aspect, this application further provides a method comprising: receiving a write command from a virtual machine (VM), the write command including a write address and data to be written; querying a configuration table to identify a zone identifier associated with the VM; amplifying the write command with the zone identifier; and issuing the write command to a memory device.

[0007] In another aspect, this application further provides a method comprising: receiving an amplified write command from a host processor, the amplified write command including a write address, data to be written, and a zone identifier; identifying a set of physical addresses associated with the zone identifier; mapping the write address to a physical address in the set of physical addresses; and writing the data to the physical address. Attached Figure Description

[0008] Figure 1 This is a block diagram of a memory device according to some embodiments of the present disclosure.

[0009] Figure 2 This is a block diagram of a host processor according to some embodiments of the present disclosure.

[0010] Figure 3 This is a flowchart of a method for preventing durability hacking according to some embodiments of the present disclosure.

[0011] Figure 4 This is a flowchart of a method for processing write commands and preventing durability hacking according to some embodiments of the present disclosure.

[0012] Figure 5 A block diagram illustrating a memory system according to some embodiments of the present disclosure.

[0013] Figure 6 A block diagram of a computing device is provided to illustrate various embodiments of the computing device used in this disclosure. Detailed Implementation

[0014] As described in the background section, wear leveling "extends" the P / E cycle across all cells of a memory array. However, malicious or poorly implemented software can exhibit a minimum leveling performance in maintaining the P / E cycle. Specifically, this software can write excessive amounts of data to the memory array. In response, the memory controller will attempt to distribute the P / E cycle across all memory cells. However, the sheer volume of writes can cause some, most, or all memory cells to reach their maximum endurance and fail. When enough data is written, the software can effectively corrupt the memory device (e.g., a solid-state drive or SSD).

[0015] In some cases, this result is unintentional. For example, login software may not contain any triggers to stop login, even when an unexpected amount of data is received. In other cases, the result is intentionally and maliciously caused. For example, a malicious user may initiate a program to intentionally write many petabytes of data to an SSD, specifically to cause the memory cell to reach its durability threshold. In yet another case, a combination of malicious action and poorly implemented software can cause the result. For example, a malicious user may employ a poorly designed login application by submitting numerous requests, causing the application to write petabytes of data (similar to a denial-of-service attack).

[0016] This scenario occurs frequently when multiple virtual machine (VM) instances run on a single host processor and access storage devices such as SSDs. For example, cloud computing platforms typically host many VMs operated by different entities. These VMs may access a single large SSD for persistent storage. Because the VMs are isolated, a portion of the SSD used by a non-malicious VM operator may be adversely affected by a malicious (or negligible) VM operator, as described above.

[0017] Figure 1 This is a block diagram of a memory device according to some embodiments of the present disclosure.

[0018] In the illustrated embodiments, the memory device (100) may include a NAND flash memory device. In one embodiment, the memory device (100) may include an SSD or other type of storage device utilizing NAND flash memory. In other embodiments, NOR flash memory may be used instead of NAND flash memory. The following description primarily discusses NAND flash memory; however, other memory types may be used. In some embodiments, any memory type may be used to increase the write endurance of individual memory cells by utilizing wear leveling (or other techniques).

[0019] In the illustrated embodiment, the memory device (100) is communicatively coupled to the host processor (200). Figure 2 The host processor (200) is described more fully in the description herein, and is incorporated herein by reference in its entirety. In simple terms, the host processor (200) can include any computer processor or computing system. For example, the host processor (200) can include a central processing unit (CPU) that executes one or more virtual machine instances. In this example, the CPU may communicate with the memory device (100) via a local bus (e.g., Peripheral Component Interconnect High Speed, PCIe, bus).

[0020] In another example, the host processor (200) may include a server computer that includes its own volatile memory and other peripheral devices. In this example, the server computer may communicate with the memory device (100) via a network. That is, the memory device (100) may include a network attached storage (NAS) device.

[0021] Generally, any computing device capable of issuing commands to a storage device can be used as a host processor, and this disclosure does not limit the specific form of the host processor (200). As will be seen in... Figure 2 As discussed in more detail herein, the host processor (200) includes one or more configuration tables for managing access to the memory device (100). Furthermore, the host processor (200) is configured to issue expanded write commands based on such configuration tables. The host processor (200) may also be able to issue other operations (e.g., read operations), but those commands are not described in detail herein, and existing operations may be used as will be discussed.

[0022] The memory device (100) includes a controller (106). In the illustrated embodiment, the controller (106) mediates all operations transmitted by the host processor (200) and any other devices. In one embodiment, the controller (106) includes a microcontroller or a computer processor. In other embodiments, the controller (106) may include a system-on-a-chip (SoC). Generally, the controller (106) contains all the logic necessary to access the memory array (104). Exemplary components of the controller (106) are described in... Figure 5 The description is in the text and will not be repeated here.

[0023] As will be discussed, the controller (106) receives requests, in particular, to read data and to write data to the memory array (104). In the illustrated embodiment, the memory array (104) may include an address space of physical memory cells addressable by the controller (106). The specific geometric arrangement of the memory array (104) is not limiting and, for ease of discussion, is presented as an array of physical addresses.

[0024] The controller (106) may include LBA-PBA mapping logic to map LBAs in read / write commands to PBAs representing addresses in the memory array (104). For each read / write command, the controller (106) generates the corresponding LBA located in the array (104). For a read operation, the controller (106) may utilize an LBA-PBA lookup table to identify the corresponding PBA. This lookup table may be populated when data is written. That is, after a successful write to a PBA, the controller (106) updates the LBA-PBA lookup table with the LBA and PBA values ​​for later reads.

[0025] In contrast, for write commands, the controller (106) can utilize the zone configuration table (108) to generate PBAs. As illustrated, the memory array (102) comprises multiple zones (102a…102n). The specific size and number of these zones (102a…102n) are not limiting. Generally, a given zone (102a…102n) comprises a sequential set of PBAs. The size can be constant or variable (i.e., dynamically expanding / shrinking). Zones (102a…102n) can include logical zones and may not include physically distinct regions of memory. In other embodiments, the memory array (104) can include multiple physically distinct structures corresponding to each zone. For example, each zone (102a…102n) may correspond to a NAND flash memory plane.

[0026] The configuration table (108) stores the mapping between fixed region identifiers and the addresses of regions (102a…102n). In the illustrated embodiment, each of the regions (102a…102n) is associated with a physical start address and a physical stop address that define its boundaries. Thus, the first region (102a) contains all physical addresses between 0 and X, the second region (102b) contains all physical addresses between X+1 and Y, and the nth region (102n) contains all physical addresses between Y+m and Z, where m includes one more address than the number between the end of region 2 (102b) and the start of region n (102n). As an example, if Figure 1 If the number of zones is three, then the value of Y+m will be equal to Y+1. In an alternative embodiment, table (108) may contain only the start address and the size of the zone in which the stop address can be calculated (i.e., the number of addresses in the zone).

[0027] As discussed and in Figure 4 As discussed in more detail below, the controller (106) uses table (108) when processing write commands. Specifically, when the host processor (200) issues a write command, the host processor (200) includes a zone identifier (ID) in the write command. A write (or procedure) operation that includes a zone ID is called an “amplified” write command to distinguish this operation from a standard write command. The write command also includes an LBA and the data to be written. In one embodiment, the LBA in the amplified command is always selected from a range of LBA values ​​starting from zero. That is, in the illustrated table (108), the LBA for zone 0 (102a) is between 0 and X, the LBA for zone 1 (102b) is between 0 and YX, and so on. In this embodiment, each zone (102a…102n) has its own zero-indexed address space. Alternatively, in some embodiments, the LBA in the write command may include any LBA in the range 0…Z in table (108). In one embodiment, the latter implementation can be used to improve compatibility with previous NAND controllers / arrays.

[0028] The controller (106) processes a write command by extracting the region ID from the write command and generating a PBA (Purpose Scale Object) within a range of start and stop address identifications in the usage table (108). In one embodiment, the generation of the PBA is performed via dedicated wear leveling logic (not described) in the controller (106). The controller (106) implements a scoped wear leveling routine, unlike existing wear leveling routines. In this scoped routine, wear leveling is performed only on addresses within a given region. Specific details on how wear leveling is managed and logged are not included herein; any existing routine may be used provided it operates as described herein.

[0029] As an example, the write command can specify the LBAs for regions 0 and 0x01. The value of X in table (108) can be 255 (0xFF). The controller (106) identifies a range of available PBAs (0x00 to 0xFF) and selects a free PBA (e.g., 0x2E) from said range. In one embodiment, the controller (106) can use an LBA-PBA mapping for said region to identify available PBAs, and can identify PBAs based on finding the PBA with the least P / E operation (i.e., wear leveling).

[0030] After recognizing the PBA as described above, the controller (106) writes the data in the amplified write command to the PBA and returns a success result to the host processor (200). Therefore, compared to existing memory devices, the PBA selectively operates on a given region, and when an amplified write command is received, only the PBA within that region can be written. In this way, even if the host processor (200) writes excessive data (e.g., 100,000*X to region 102a), those cells in that region will fail, while other regions (e.g., 102b, 102n) will remain unaffected. In this way, malicious or poorly programmed software on the host processor (especially multi-intensity processors) cannot adversely affect the entire shared memory device (100).

[0031] Finally, in some embodiments, the controller (106) typically handles read operations. Specifically, the host processor (200) will subsequently issue a read operation containing the LBA requested in the write command. In some embodiments, the controller (106) maintains a global LBA-PBA lookup table to handle read operations, and thus identifies the PBA, reads, and returns the data. Alternatively, if the region is zero-indexed, the controller (106) may store a per-region LBA-PBA table. In this alternative, the read operation will contain the region ID, and the controller (106) will load the corresponding scope region LBA-PBA table to perform PBA mapping. The controller (106) then typically reads the data from the identified PBA and returns the read value.

[0032] As described above, the host processor (200) ultimately amplifies the write command with the zone ID. In some embodiments, the host processor (200) includes a super manager that intercepts standard write commands and inserts the zone ID based on a mapping (e.g., a VM-to-zone mapping). Further details regarding this aspect of the embodiment are described more fully in the following figures.

[0033] Figure 2 This is a block diagram of a host processor according to some embodiments of the present disclosure.

[0034] In the illustrated embodiment, the memory device (100) is communicatively coupled to the host processor (200). The host processor (200) may include any computer processor or computing system. For example, the host processor (200) may include a central processing unit (CPU) that executes one or more virtual machine instances. In this example, the CPU may communicate with the memory device (100) via a local bus (e.g., Peripheral Component Interconnect High Speed, PCIe, bus).

[0035] In another example, the host processor (200) may include a server computer that includes its own volatile memory and other peripheral devices. In this example, the server computer may communicate with the memory device (100) via a network. That is, the memory device (100) may include a network attached storage (NAS) device.

[0036] The host processor (200) is configured to issue expanded write commands based on such a configuration table. The host processor (200) may also be able to issue other operations (e.g., read operations), but those commands are not described in detail herein, and existing operations may be used as will be discussed.

[0037] In the illustrated embodiment, the host processor (200) includes a super manager (202). In the illustrated embodiment, the super manager (202) includes computer software, firmware, or hardware that creates and runs virtual machines (VMs) containing VMs (204a to 204n). The super manager (202) enables the VMs (204a to 204n) to share available resources (e.g., CPU, volatile memory, and access to memory device 100) and provides greater mobility because the VMs (204a to 204n) are independent of the hardware of the host processor (200).

[0038] In the illustrated embodiments, each VM (204a to 204n) executes one or more applications. There is no limitation on the type of applications running on the VMs (204a to 204n). For example, a VM (204a) may implement a complete operating system (OS) and one or more user-level applications running thereon. In another embodiment, containers or other virtualization technologies may be used in place of VMs and in combination with them. For example, VM (204b) may actually be... Containers or Kubernetes containers. Other virtualization or container technologies can be used. However, generally, each VM (204a to 204n) is capable of accessing a storage device (100) to store and retrieve data. Figure 1 As described herein, in some embodiments, the memory device (100) includes an SSD, and therefore includes a non-volatile storage device connected to the host processor (200) for storing data through applications running on the VM (204a to 204n).

[0039] In the illustrated embodiment, each VM (204a to 204n) can access the memory device (100). Furthermore, communication between the VMs (204a to 204n) and the memory device (100) is mediated by a super manager (202). Therefore, if a given VM (204a to 204n) accesses the memory device (100), that access is intercepted by the super manager (202). In one embodiment, each VM (204a to 204n) issues standardized commands to access the memory device (100). For example, each VM (204a to 204n) can issue standard POSIX (Portable Operating System Interface) commands to access the SSD including the memory device (100). The super manager (202) receives these commands and forwards them as operations to the memory device (100).

[0040] In the illustrated embodiment, the super manager (202) maintains a VM configuration table (206). In the illustrated embodiment, the table (206) includes a mapping of VMs (204a to 204n) to zones of the memory device (100). As illustrated, the table (206) specifically maps VM (204a to 204n) identifiers to zone IDs. In some embodiments, each VM (204a to 204n) is mapped to a different zone of the memory device (100). However, as illustrated, in some embodiments, multiple VMs (204a, 204b) may be mapped to the same zone ID.

[0041] In Figure 3In one embodiment described in more detail, the super manager (202) retrieves or generates a list of available zone IDs for use by the memory device (100). Specifically, in one embodiment, the memory device (100) manages its own zones, and therefore the super manager (202) retrieves a list of zone IDs and metadata (e.g., size, etc.) from the memory device (100). In another embodiment, the super manager (202) may manage the allocation of zones in the memory device (100). In this embodiment, the super manager (202) may initialize a first number of zones at startup and transmit instructions to the memory device (100) to populate the zone configuration table (108) based on the desired number and size of said zones. In one embodiment, the super manager (202) manages the zone configuration table (108) sequentially based on the allocation of VMs (204a to 204n). Thus, at startup, the super manager (202) may initialize a single zone (0) and start a first VM. When a second VM is requested, the super manager (202) can “shrink” the first partition (0) and add a new partition (1) to accommodate the second VM, etc.

[0042] As illustrated, in both embodiments above, the super manager (202) also maintains a table mapping VMs (204a to 204n) to zone IDs. In one embodiment, the super manager (202) maintains a list of available zone IDs identified from the memory device (100) and allocates unused zone IDs to new VMs, as well as reclaiming zone IDs from terminated VMs. In another embodiment, the super manager (202) may simultaneously create new zones in the memory device (100) when a VM is started and a new VM is automatically associated with a new zone in the table (206). In the illustrated embodiments, the table (206) may be stored in volatile memory connected to the host processor (or, if available, in onboard volatile memory) and persisted to disk for VM recovery. In one embodiment, the host processor (200) persists the table (206) to a dedicated zone (not illustrated) of the memory device (100) before shutdown.

[0043] Figure 3 and 4 Further details regarding the operation of the host processor (200) and memory devices (100) are provided. These operational details are incorporated as needed. Figure 1 and 2 middle.

[0044] Figure 3 This is a flowchart of a method for preventing durability hacking according to some embodiments of the present disclosure. In one embodiment, Figure 3 The methods described herein can be executed by the host processor, and in some embodiments, by a super manager running on the host processor.

[0045] In box 302, the method obtains a list of region IDs. In the illustrated embodiment, the super manager executes box 302 upon startup.

[0046] In a first embodiment, the method obtains a list of zone IDs by querying the memory device. In this embodiment, when the memory device boots up, it creates multiple zones and stores them in a zone configuration table. In one embodiment, the memory device creates a fixed set of equal-sized zones and stores the zone details in the table. Then, when the super manager is initialized, it issues a command to read the zone IDs from the memory device and thus obtain the zone IDs.

[0047] In a second embodiment, the method obtains a list of zone IDs by generating zone IDs. In this embodiment, the method queries the memory device to determine the available capacity of the basic memory array. Based on the capacity, the method divides the total capacity into one or more zones. The method may randomly determine the number of zones, either by one or by any other means (e.g., the number of VMs to be initialized). The method thus obtains a list of zone IDs locally and controls the initial allocation of zones on the memory device.

[0048] If the first embodiment is implemented, the method proceeds to block 306. If the second embodiment is implemented, the method proceeds to block 304. In block 304, the method transfers region data to a memory device. In one embodiment, the method transfers the number of requested regions to the memory device. In response, the memory device can divide the memory array into the number of requested regions. In one embodiment, the memory device can divide the requested regions into evenly sized portions.

[0049] In a second embodiment, the method may transmit the number of requested zones and the desired size of one or more zones. For example, the method may request two zones with sizes of 1GB and 2GB. As another example, the method may request three zones with 30%, 20%, and 50% of the available capacity. Various other methods may be used. In response, the memory device attempts to allocate each zone. The allocation of each zone includes writing a start address and a stop address into a zone configuration table stored in the memory device. In one embodiment, the memory device may determine whether the request is valid. For example, the memory device may determine whether the requested capacity (if using the original capacity) is available (or exists). If a percentage is used, then the memory device may confirm that the requested total percentage is less than or equal to 100%. The memory device may then proceed to allocate the zones sequentially by calculating the start and stop addresses of each zone and writing these addresses into the zone configuration table. For example, if two zones are requested, each with 50% capacity, then the method writes zone 0 with a start address of 0x0 and a stop address of 0xN / 2, where N is the available capacity of the memory array. The memory device then writes the next region to a table with a start address of 0x(N / 2+1) and an end address of 0xN. The memory device continues processing each region until all regions have been recorded in the table. It is worth noting that in some embodiments, the memory device will not modify the underlying physical storage and will manage regions entirely using local tables.

[0050] In some embodiments, if block 304 is implemented, the memory device returns the region identifiers generated during the above process. In this scenario, when block 302 is executed, the host processor does not assign identifiers to the regions but waits for identifier assignment from the memory device. In this way, the requested regions and the returned region identifiers may not be in a consistent order. That is, the host processor may request regions A, B, and C, but the memory device may assign A=3, B=1, and C=2 (compared to assigning A=1, B=2, and C=3). Due to this potential "reordering," the method may wait for identifier confirmation before proceeding to block 306.

[0051] In block 306, the method assigns one or more VMs to corresponding region identifiers. In some embodiments, the method maps each VM to a different region of the memory device. However, in some embodiments, the method may map multiple VMs to the same region ID. In some embodiments, the region ID is chosen randomly. In other embodiments, the method sorts the region IDs and maps them from lowest to highest (or vice versa). After assigning each VM to a region ID, the method writes this mapping to a VM configuration table (206).

[0052] In block 308, the method receives a write command from the VM. In the illustrated embodiments, the write command includes a command to write data to a storage device, such as an SSD. In the illustrated embodiments, each VM may issue a command to access the underlying storage medium without knowing the underlying implementation of the storage device. Therefore, standard system calls can be used to issue the write command. As described above, in some embodiments, the method is executed by the super manager, and therefore the method intercepts the write commands issued by each VM in block 308. In some embodiments, the write command includes an LBA and data to be written.

[0053] In block 310, the method identifies the region associated with the VM. In the illustrated embodiments, the method may associate each write command with a specific VM. In some embodiments, each VM is associated with a unique identifier known to the method (e.g., known to the super manager executing the method). Thus, when the super manager receives a write command, it can identify the VM identifier associated with the VM that issued the write command.

[0054] Next, the method queries the table that maps VM identifiers to region identifiers. Combined with... Figure 2 Table (206) describes this table, and the description will not be repeated herein. After querying the table, the method thus identifies the region identifier of the VM that issued the correct command.

[0055] In block 312, the method augments the write command with a zone identifier. In one embodiment, the method adds the zone identifier to a configuration section of the write command. In another embodiment, the method may issue a separate command containing the zone identifier. That is, the method may translate a standard write command into a dedicated write command that is handled by different logic in the memory device firmware. In either case, the method includes a write address (e.g., LBA) and data, as well as the zone identifier.

[0056] In box 314, the method issues an expanded write command to the memory device. As discussed above, Figure 3 The methods described can be executed by the host processor, and in some embodiments, by the super manager. Therefore, in block 314, the means executing the methods issues commands to the memory device via a suitable interface. This interface may include an internal bus (e.g., a PCIe bus) or a network, and specific interconnects are not limiting. (As will be combined...) Figure 4 In more detail, the memory device receives an augmented write command, which is specifically processed for writing based on a region ID.

[0057] Figure 4 This is a flowchart of a method for processing write commands and preventing durability hacking according to some embodiments of the present disclosure.

[0058] In step 402, the method receives the amplified write command.

[0059] In the illustrated embodiment, the amplified write command includes commands from... Figure 3 The write commands generated by the process described herein are incorporated herein by reference in their entirety. In some embodiments, Figure 4 The method is executed by a storage device, such as an SSD, and more specifically, by the controller of that device. As described above, the amplified write command includes a zone identifier set by the supermanager before the command is issued. The write command also includes a write address (e.g., LBA) and the data to be written. The write command can be received via a local interconnect (e.g., PCIe) or a network interface.

[0060] In step 404, the method moves from the write command identification area.

[0061] In one embodiment, the method extracts a region identifier from the amplified write command. For example, the method may analyze the configuration section of the command to identify the region identifier. The method may verify that the region identifier is valid (i.e., within the range of valid identifiers or properly formatted) before proceeding.

[0062] Next, the method queries a region configuration table (e.g., 108) to identify the range of physical addresses. As described above, the memory device may store a region configuration table (e.g., 108) that maps region identifiers to start addresses and, in some embodiments, stops the memory region's address. In other embodiments, the region configuration table (e.g., 108) stores a mapping between region identifiers and start addresses and address space sizes.

[0063] In step 406, the method performs physical address lookup and wear leveling on the region.

[0064] After identifying the physical address range in step 404, the method selects a physical address for writing data using write address mapping. In a first embodiment, the method selects a random physical address that is not used within the range of the region. However, in other embodiments, the method performs wear leveling on the region to prevent cell damage and distributes operations across the region.

[0065] The method can use dynamic wear leveling or static wear leveling, which operates on a specific region rather than the entire physical address space. Depending on the wear leveling method used, the method typically either writes to the available erase block with the lowest erase count (dynamic wear leveling); or selects the available target block with the lowest overall erase count, erases the block if necessary, writes new data to the block, and ensures that static data blocks are moved when the erase count of static data blocks falls below a certain threshold (static wear leveling).

[0066] In a dynamic wear leveling implementation, the method aggregates available blocks that do not contain data and selects the block with the lowest erase count for the next write. This method is highly effective for dynamic data because it only wear levels the non-static portion of the NAND flash array. Systems implementing dynamic wear leveling achieve longer NAND flash device lifespans than systems that do not implement wear leveling.

[0067] In a static wear leveling implementation, the method utilizes all good blocks to evenly distribute wear, thereby providing effective wear leveling and extending device life. This method tracks the cycle count of all good blocks and attempts to evenly distribute block wear throughout the device by selecting the available block with the least wear each time a programming operation is performed. Static data is managed by keeping all blocks within a certain erase count threshold. Blocks containing static data are included in a wear leveling block pool, the static data having an erase count that begins to lag behind other blocks, whereby the static data moves to blocks with higher erase counts.

[0068] It is worth noting that any or all wear leveling algorithms can be used. However, the method explicitly applies wear leveling to regions rather than the global address space. Therefore, data in regions (and thus the VM) is distributed between regions rather than throughout the entire device.

[0069] In step 408, the method writes data to the physical address identified in step 406. In the illustrated embodiment, the method writes data to the physical address after identification. As described above, any technique for writing data to the memory array can be used after physical address identification.

[0070] Figure 5 A block diagram illustrating a memory system according to some embodiments of the present disclosure.

[0071] like Figure 5 As described herein, the computing system (500) includes a processor (200) communicatively coupled to a memory system (100) via a bus (504). The memory system (100) includes a controller (106) communicatively coupled to one or more memory groups (508a to 508n) forming a memory array (104) via a bus / interface (512). As described herein, the controller (106) includes a local cache (514), firmware (516), and an ECC module (520).

[0072] In the illustrated embodiments, the processor (200) may include any type of computer processor, such as a central processing unit (CPU), a graphics processing unit (GPU), or other type of general-purpose or special-purpose computing device. The processor (200) includes one or more output ports that allow the transfer of address, user, and control data between the processor (200) and the memory system (100). In the illustrated embodiments, this communication is performed via a bus (504). In one embodiment, the bus (504) includes an input / output (I / O) bus or a similar type of bus.

[0073] The memory system (100) manages one or more memory groups (508a to 508n). In one embodiment, the group (508a to 508n) includes other configurations of NAND flash dies or non-volatile memory. In one embodiment, the memory group (508a to 508n) includes a memory array, such as a memory array (104).

[0074] Groups (508a to 508n) are managed by a controller (106). In some embodiments, the controller (106) includes a computing device configured to mediate access to and from groups (508a to 508n). In one embodiment, the controller (106) includes an ASIC or other circuitry mounted on a printed circuit board housing the groups (508a to 508n). In some embodiments, the controller (106) may be physically decoupled from the groups (508a to 508n). The controller (106) communicates with the groups (508a to 508n) via an interface (512). In some embodiments, this interface (512) includes a physically wired (e.g., trace) interface. In other embodiments, the interface (512) includes a standard bus for communicating with the groups (508a to 508n).

[0075] The controller (106) includes various modules (514 to 518). In one embodiment, the various modules (514 to 518) include various physically different modules or circuits. In other embodiments, the modules (514 to 518) may be fully (or partially) implemented in software or firmware.

[0076] As explained, the firmware (516) comprises the core of the controller and manages all operations of the controller (106). The firmware (516) may implement some or all of the methods described above. Specifically, the firmware (516) may implement... Figure 1 and 4 The method described in [the document / document].

[0077] Figure 6 A block diagram of a computing device is provided to illustrate various embodiments of the computing device used in this disclosure.

[0078] The computing device (600) may include a ratio Figure 6 The components shown may include more or fewer components. For example, a server computing device may not include an audio interface, display, keypad, lights, haptic interface, GPS receiver, camera, or sensors.

[0079] As shown in the figure, the device (600) includes a processing unit (CPU) (622) that communicates with a mass storage device (630) via a bus (624). The computing device (600) also includes one or more network interfaces (650), an audio interface (652), a display (654), a keypad (656), a illuminator (658), an input / output interface (660), a haptic interface (662), an optional Global Positioning System (GPS) receiver (664), and a camera or other optical, thermal, or electromagnetic sensor (666). As will be understood by those skilled in the art, the device (600) may include one or more cameras / sensors (666). The positioning of the camera / sensor (666) on the device (600) may vary depending on the device (600) model, the capabilities of each device (600), or a combination thereof.

[0080] The computing device (600) may optionally communicate with a base station (not shown) or directly with another computing device. The network interface (650) is sometimes referred to as a transceiver, transceiver device, or network interface card (NIC).

[0081] An audio interface (652) generates and receives audio signals, such as the sound of human speech. For example, the audio interface (652) may be coupled to a speaker and a microphone (not shown) to enable telecommunications with other people or to generate audio confirmation for some action. The display (654) may be a liquid crystal display (LCD), a gas plasma display, a light-emitting diode (LED), or any other type of display used with a computing device. The display (654) may also include a touch-sensitive screen arranged to receive input from an object such as a stylus or a finger from a human hand.

[0082] The keypad (656) may include any input device arranged to receive input from the user. The illuminator (658) may provide status indication or provide light.

[0083] The computing device (600) also includes an input / output interface (660) for communicating with external devices using communication technologies such as USB, infrared, and Bluetooth. TM The haptic interface (662) provides haptic feedback to the user of the client device.

[0084] An optional GPS transceiver (664) can determine the physical coordinates of the computing device (600) on the Earth's surface, typically outputting the location as latitude and longitude values. The GPS transceiver (664) may also employ other geolocation mechanisms, including but not limited to triangulation, assisted GPS (AGPS), E-OTD, CI, SAI, ETA, BSS, etc., to further determine the physical location of the computing device (600) on the Earth's surface. However, in one embodiment, the computing device (600) may be provided with additional information that can be used to determine the device's physical location via other components, including, for example, a MAC address, an Internet Protocol (IP) address, etc.

[0085] Mass storage (630) includes RAM (632), ROM (634), and other storage components. Mass storage (630) illustrates another example of a computer storage medium used to store information such as computer-readable instructions, data structures, program modules, or other data. Mass storage (630) stores a basic input / output system (“BIOS”) (640) for controlling the low-level operations of the computing device (600). Mass storage also stores an operating system (641) for controlling the operation of the computing device (600).

[0086] The application (642) may contain computer-executable instructions that, when executed by a computing device (600), perform any of the methods (or portions thereof) previously described in the description of the preceding figures. In some embodiments, software or programs implementing the method embodiments may be read from a hard disk drive (not shown) and temporarily stored in RAM (632) by a CPU (622). The CPU (622) may then read the software or data from RAM (632), process the software or data, and store it back into RAM (632).

[0087] This disclosure includes various means for performing the methods and implementing the systems described above, including a data processing system for performing these methods, and a computer-readable medium containing instructions that, when executed on the data processing system, cause the system to perform the methods.

[0088] The descriptions and figures are illustrative and should not be construed as limiting. Many specific details are described to provide a thorough understanding. However, in some instances, well-known or conventional details are omitted to avoid obscuring the description. References to "one" or "a" embodiment in this disclosure do not necessarily refer to the same embodiment; and such references imply at least one.

[0089] References to "one embodiment" or "an embodiment" in this specification mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of this disclosure. The phrase "in one embodiment" appearing in various places throughout this specification does not necessarily refer to the exact same embodiment, nor is it necessarily a separate or alternative embodiment that is mutually exclusive with other embodiments. Furthermore, various features that may be presented by some embodiments but not by others are described. Similarly, various requirements are described, which may be requirements for some embodiments but not others.

[0090] In this description, various functions and operations may be described as being executed or caused by software code for the sake of simplicity. However, those skilled in the art will recognize that such expressions mean that the functions are caused by the execution of code by one or more processors, such as microprocessors, application-specific integrated circuits (ASICs), graphics processors, or field-programmable gate arrays (FPGAs). Alternatively or in combination, functions and operations may be implemented using dedicated circuit systems (e.g., logic circuit systems) with or without software instructions. Embodiments may be implemented using hardwired circuit systems without software instructions or in combination with software instructions. Therefore, the techniques described are not limited to any particular combination of hardware circuit systems and software, nor are they limited to any particular source of instructions executed by a computing device.

[0091] While some embodiments can be implemented in fully functional computers and computer systems, various embodiments can be distributed as computing products in a variety of forms and are applicable regardless of the specific type of machine or computer-readable medium used to implement the distribution.

[0092] At least some of the disclosed aspects can be implemented, at least partially, in software. That is, the techniques can be performed in a computing device or other system in response to its processor (e.g., a microprocessor) executing a sequence of instructions contained in memory (e.g., ROM, volatile RAM, non-volatile memory, cache, or remote storage device).

[0093] The routines executed to implement embodiments can be implemented as part of an operating system, middleware, business delivery platform, software development kit (SDK) components, network services, or other specific applications, components, programs, objects, modules, or sequences of instructions referred to as "computer programs." The calling interface to these routines can be exposed to the software development community as an application programming interface (API). Computer programs typically include one or more sets of instructions stored in various memories and storage devices within a computer at various times, and these sets of instructions, when read and executed by one or more processors in the computer, cause the computer to perform operations necessary to perform elements involving various aspects.

[0094] Machine-readable media can be used to store software and data that, when executed by a computing device, causes the device to perform various methods. Executable software and data can be stored in various locations, including, for example, ROM, volatile RAM, non-volatile memory, or cache. A portion of this software or data can be stored in any of these storage devices. Additionally, data and instructions can be obtained from a centralized server or peer-to-peer network. Different portions of data and instructions can be obtained from different centralized servers or peer-to-peer networks at different times and in different communication sessions or within the same communication session. All data and instructions can be obtained before the application is executed. Alternatively, portions of data and instructions can be obtained dynamically and as needed for execution. Therefore, it is not required that all data and instructions be on the machine-readable medium at any given time.

[0095] Examples of computer-readable media include, but are not limited to, recordable and non-recordable media, such as volatile and non-volatile memory devices, read-only memory (ROM), random access memory (RAM), flash memory devices, solid-state drive storage media, removable disks, disk storage media, optical storage media (e.g., optical disc read-only memory (CD-ROM), digital versatile optical disc (DVD), etc.), and other media. Computer-readable media can store instructions.

[0096] Generally, tangible or non-transitory machine-readable media include any mechanism that provides (e.g., stores) information in a form accessible to a machine (e.g., a computer, mobile device, network device, personal digital assistant, manufacturing tool, any device having one or more processors, etc.).

[0097] In various embodiments, hardwired circuitry systems can be used in combination with software and firmware instructions to implement the technology. Therefore, the technology is neither limited to any particular combination of hardware circuitry systems and software, nor to any particular source of instructions executed by a computing device.

[0098] A wide variety of computing devices of different types can be used to implement the various embodiments described herein. As used herein, examples of “computing devices” include, but are not limited to, servers, centralized computing platforms, systems with multiple computing processors or mobile devices, user terminals, vehicles, personal communication devices, wearable digital devices, electronic self-service terminals, general-purpose computers, electronic document readers, tablet computers, laptop computers, smartphones, digital cameras, home appliances, televisions, or digital music players. Additional examples of computing devices include devices that are part of a concept known as the “Internet of Things” (IoT). Such “things” may interact incidentally with their owners or administrators who may monitor or modify settings on these things. In some cases, such owners or administrators act as users of the “thing” devices. In some instances, a user’s primary mobile device (e.g., an Apple iPhone) may be an administrator server for paired “thing” devices worn by the user (e.g., an Apple Watch).

[0099] In some embodiments, the computing device may be a computer or a host system, such as a desktop computer, laptop computer, web server, mobile device, or another computing device including memory and processing means. The host system may include or be coupled to a memory subsystem, such that the host system can read data from or write data to the memory subsystem. The host system may be coupled to the memory subsystem via a physical host interface. Generally, the host system may access multiple memory subsystems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0100] In some embodiments, the computing device is a system comprising one or more processing devices. Examples of processing devices may include a microcontroller, a central processing unit (CPU), a dedicated logic circuit system (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), a system-on-a-chip (SoC), or another suitable processor.

[0101] Although some diagrams illustrate several operations in a specific order, non-orderly dependent operations can be reordered and other operations can be combined or decomposed. While some reorderings or other groupings are specifically mentioned, other reorderings or groupings will be obvious to those skilled in the art, and therefore an exhaustive list of alternatives is not provided. Furthermore, it should be recognized that stages can be implemented in hardware, firmware, software, or any combination thereof.

[0102] In the foregoing description, this disclosure has been described with reference to specific exemplary embodiments thereof. It will be apparent that various modifications may be made thereto without departing from the broader spirit and scope set forth in the appended claims. Therefore, the description and drawings should be regarded in an illustrative rather than restrictive sense.

Claims

1. A memory system comprising: The host processor and memory device, wherein The host processor is configured to receive write commands from a virtual machine, identify a region identifier associated with the virtual machine, amplify the write command using the region identifier, and issue the write command to the memory device. The memory device is configured to receive the write command, use a zone configuration table to identify zones that include a subset of addresses writable by the memory device, and write data to addresses in the subset of addresses.

2. The memory system of claim 1, wherein the host processor includes a super manager.

3. The memory system of claim 1, wherein the memory device comprises a solid-state drive (SSD).

4. The memory system of claim 3, wherein the memory device further comprises a NAND flash memory array.

5. The memory system of claim 1, wherein the host processor maps a plurality of virtual machines to a plurality of corresponding region identifiers, wherein at least two of the plurality of virtual machines are mapped to the same region identifier.

6. The memory system of claim 1, wherein the host processor maps a plurality of virtual machines to a plurality of unique corresponding region identifiers.

7. The memory system of claim 1, wherein the host processor is configured to amplify the write command with the zone identifier by inserting the zone identifier into a configuration segment of the write command.

8. The memory system of claim 1, wherein the host processor is configured to issue the write command to the memory device via a high-speed PCIe bus connected via peripheral components interconnect.

9. The memory system of claim 1, wherein the host processor is configured to issue the write command to the memory device by issuing the write command via a network.

10. The memory system of claim 1, wherein the host processor is configured to generate a set of region identifiers based on the capacity of the memory device, wherein the host processor is configured to transmit the set of region identifiers to the memory device.

11. The memory system of claim 10, wherein the memory device is configured to initialize the zone configuration table in response to receiving the set of zone identifiers.

12. The memory system of claim 1, wherein the memory device is configured to map physical addresses in the region to the write command.

13. The memory system of claim 12, wherein the memory device is configured to perform wear leveling on the region prior to mapping the physical address to the write command.

14. A method for operating a memory system, the method comprising: Receive a write command from the virtual machine (VM), the write command containing the write address and the data to be written; Query the configuration table to identify the region identifier associated with the VM; The write command is amplified using the area identifier; and The write command is issued to the memory device.

15. The method of claim 14, further comprising: The memory device is queried against the set of available addresses; The available address set is divided into multiple zones; Assign a corresponding zone identifier to each of the plurality of zones; as well as The corresponding area identifier is transmitted to the memory device.

16. The method of claim 14, further comprising assigning the VM to the region identifier in response to the instantiation of the VM.

17. The method of claim 14, wherein amplifying the write command with the zone identifier comprises inserting the zone identifier into a configuration segment of the write command.

18. A method for operating a memory system, the method comprising: Receive an amplified write command from the host processor, the amplified write command including a write address, data to be written, and a region identifier; Use the zone configuration table to identify the set of physical addresses associated with the zone identifier; Map the write address to a physical address in the physical address set; and The data to be written is written to the physical address.

19. The method of claim 18, further comprising performing wear leveling on the set of physical addresses before mapping the physical addresses to the write addresses.

20. The method of claim 18, further comprising initializing the zone configuration table based on a set of zone identifiers received from the host processor.

Images