CN117873370A

CN117873370A - System, method and apparatus for protecting device data transfer

Info

Publication number: CN117873370A
Application number: CN202311309158.2A
Authority: CN
Inventors: D·L·赫尔米克; 金志守; 芮祥荣; E·希巴德
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2022-10-12
Filing date: 2023-10-10
Publication date: 2024-04-12

Abstract

An apparatus may include a device including a first controller and a second controller, where the device may be configured to receive data using the first controller, apply a first protection scheme to the data, and transmit data from the device with a second protection scheme using the second controller. The first protection scheme and the second protection scheme may be the same. The second controller may be configured to apply a second protection scheme to the data. The first protection scheme may include a first salt value and the second protection scheme may include a second salt value. The first salt value may be determined by the device and the second salt value may be determined by the user. The method may further include applying, at the device, a third protection scheme to the controller state information of the first controller to generate controller state information having the third protection scheme.

Description

System, method and apparatus for protecting device data transfer

Citation of related application

The present application claims priority and benefit from U.S. provisional patent application serial No. 63/415,624 filed on 10 months 12 of 2022 and U.S. provisional patent application serial No. 63/415,626 filed on 10 months 12 of 2022, both of which are incorporated herein by reference.

Technical Field

The present disclosure relates generally to data transfer and, more particularly, to systems, methods, and apparatus for protecting device data transfer.

Background

Processing operations may be relocated for one or more reasons such as availability of resources, power down, cost, efficiency, and/or the like. For example, programs, operating systems, virtual machines, and/or the like that use a first set of processing and/or storage resources in a data center may be relocated to use a second set of processing and/or storage resources at a different location within the data center, at a different data center, and/or the like. The relocation process operation may involve the transfer of data such as status information, metadata, user data, and/or the like.

The above information disclosed in this background section is only for enhancement of understanding of the background of some aspects of the present disclosure and therefore it may contain information that does not form the prior art.

Disclosure of Invention

A method may include performing, by a controller at a device, a first access to a namespace of the device using a first namespace identifier and performing a second access to the namespace of the device using a second namespace identifier, wherein the second namespace identifier may include first information for determining the first namespace identifier and second information for identifying the controller. The first information may include a first namespace identifier and the second information may include a controller identifier of the controller. The second namespace identifier may include a first namespace identifier that is associated with the controller identification Fu Jilian. The second namespace identifier can include third information identifying a port associated with the controller. The first information may include a first namespace identifier, the second information may include a controller identifier of the controller, and the third information may include a port identifier of the port. The second namespace identifier may include a concatenation of the first namespace identifier, the controller identifier, and the port identifier. The controller may comprise a storage protocol controller. The controller may include at least a portion of a communication endpoint. The communication endpoint may include at least a portion of the functionality of the interconnect interface. The communication endpoint may comprise at least a portion of a network endpoint. The controller may be a first controller and the second access may be performed by a second controller at the device. The first controller may include a child controller and the second controller may include a parent controller. The second controller may include a main controller, and the first controller may include a sub controller. The first controller may include at least a portion of a first physical function and the second controller may include at least a portion of a second physical function. The second controller may include at least a portion of a physical function and the first controller may include at least a portion of a virtual function. The second controller may include at least a portion of a non-volatile memory (NVM) subsystem and the first controller may include at least a portion of a derived NVM subsystem based on the NVM subsystem. The first controller may include a secondary controller for storing a protocol, and the second controller may include a primary controller for storing a protocol. The first controller may use the data queue to perform the first access. The second controller may use the management queue to perform the second access. The second controller may use the data queue to perform the second access. The first namespace identifier can be determined using at least a first portion of the hardware path and the second namespace identifier can be determined using at least a second portion of the hardware path. The first access may be performed by the controller based on the first privilege, and the second access may be performed by the controller based on the second privilege. The first namespace identifier can be determined using at least a first portion of the hardware path and the second namespace identifier can be determined using at least a second portion of the hardware path.

An apparatus may include a device including a controller configured to perform a first access to a namespace of the device using a first namespace identifier, wherein the device may be configured to perform a second access to the namespace of the device using a second namespace identifier, and wherein the second namespace identifier may include first information for determining the first namespace identifier and second information for identifying the controller. The first information may include a first namespace identifier and the second information may include a controller identifier of the controller. The second namespace identifier may include a first namespace identifier that is associated with the controller identification Fu Jilian. The controller may be a first controller and the device may further include a second controller configured to perform a second access. The first controller may include a child controller and the second controller may include a parent controller. The second controller may comprise a master controller and the first controller may comprise an associated slave controller. The second controller may include at least a portion of a physical function and the first controller may include at least a portion of a virtual function. The second namespace identifier can include third information identifying a port associated with the controller. The controller may comprise a storage protocol controller. The controller may include at least a portion of a communication endpoint. The communication endpoint may include at least a portion of the functionality of the interconnect interface or at least a portion of the network endpoint. The first controller may include at least a portion of a first physical function and the second controller may include at least a portion of a second physical function. The second controller may include at least a portion of a non-volatile memory (NVM) subsystem and the first controller may include at least a portion of a derived NVM subsystem based on the NVM subsystem. The first controller may include a secondary controller for storing a protocol, and the second controller may include a primary controller for storing a protocol. The controller may be configured to perform a first access based on the first privilege and a second access based on the second privilege.

An apparatus may include a first user configured to perform a first access to a namespace of a device using a first namespace identifier and a second user configured to perform a second access to the namespace of the device using a second namespace identifier, wherein the second namespace identifier may include first information to determine the first namespace identifier and second information to identify a controller of the device. The first user may include at least one of a host, a device, a virtual machine, or a virtual machine manager. The first information may include a first namespace identifier and the second information may include a controller identifier of the controller. The second namespace identifier may include a first namespace identifier that is associated with the controller identification Fu Jilian. The second user may be configured to migrate the first user using the second access.

An apparatus may include a device including a first controller and a second controller, wherein the device may be configured to receive data using the first controller, apply a first protection scheme to the data, and transmit data from the device with a second protection scheme using the second controller. The first protection scheme and the second protection scheme may be the same. The second controller may be configured to apply a second protection scheme to the data. The first protection scheme may include a salt value (salt). The salt value may be a first salt value and the second protection scheme may include a second salt value. The first salt value may be determined by the device and the second salt value may be determined by the user. The first protection scheme may be based on a first key associated with the first request and a second key associated with the second request. The first protection scheme may include a first type of encryption and the second protection scheme may include a second type of encryption. The apparatus may be configured to apply a third protection scheme to the controller state information of the first controller to generate controller state information having the third protection scheme. The second controller may be configured to transmit controller state information having a third protection scheme from the device. The third protection scheme may be the same as the first protection scheme or the second protection scheme. The data may be first data and the device may be configured to receive second data having a second protection scheme using the second controller and apply the first protection scheme to the second data.

A method may include receiving data at a device using a first controller, applying a first protection scheme to the data at the device, and transmitting data from the device with a second protection scheme using a second controller. The first protection scheme and the second protection scheme may be the same. The method may further comprise: at the device, a second protection scheme is applied to the data. The method may further include applying, at the device, a third protection scheme to the controller state information of the first controller to generate controller state information having the third protection scheme. The method may further include transmitting controller state information having a third protection scheme from the device using the second controller.

An apparatus may include a device including a first controller and a second controller, wherein the device may be configured to receive first data using the first controller, apply a first protection scheme to the first data, generate second data based on the first data, and transmit the second data from the device with the second protection scheme using the second controller. The apparatus may be configured to generate first data having a first protection scheme and generate second data having a second protection scheme by performing an operation on the first data having the first protection scheme.

An apparatus may include a device including a first controller and a second controller, wherein the device may be configured to receive data having a first protection scheme using the first controller, apply a second protection scheme to the data, and transmit the data having the second protection scheme from the device using the second controller.

An apparatus may include a device including a first controller and a second controller, wherein the device may be configured to apply a protection scheme to controller state information of the first controller to generate controller state information having the protection scheme, and to transmit the controller state information having the protection scheme from the device using the second controller.

An apparatus may include a device including a first controller and a second controller, wherein the device may be configured to receive controller state information with a protection scheme using the first controller and provide the controller state information to the second controller.

An apparatus may include a device including a first controller and a second controller, wherein the device may be configured to receive first data having a first protection scheme using the first controller, apply a second protection scheme to the first data, generate second data based on the first data, and transmit second data having the second protection scheme from the device using the second controller. The device may be configured to generate second data having a second protection scheme by performing an operation on the first data having the first protection scheme.

An apparatus may include: a communication interface configured to communicate with a device; and user logic configured to determine a portion of the protection scheme for the data migration operation and transmit the portion of the protection scheme to the device using the communication interface. The portion of the protection scheme may include a salt value. The portion of the protection scheme may include an encryption algorithm. The portion of the protection scheme may be based on a first key associated with the first request and a second key associated with the second request.

Drawings

The figures are not necessarily to scale and elements of similar structure or function may generally be represented by like reference numerals or parts thereof throughout the figures for illustrative purposes. The drawings are only intended to facilitate the description of the various embodiments described herein. The figures do not describe every aspect of the teachings disclosed herein and do not limit the scope of the claims. In order to prevent the drawing from becoming obscure, not all components, connections and/or the like may be shown, and not all components have reference numerals. However, the pattern of the component configuration can be easily understood from the drawings. The accompanying drawings illustrate example embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosure.

Fig. 1 illustrates an embodiment of a system with a namespace identifier, according to an example embodiment of the present disclosure.

Fig. 2 illustrates an embodiment of a first namespace access scheme using a namespace identifier, according to an example embodiment of the present disclosure.

Fig. 3 illustrates an embodiment of a second namespace access scheme using a namespace identifier, according to an example embodiment of the present disclosure.

Fig. 4 illustrates an embodiment of a third namespace access scheme using a namespace identifier, according to an example embodiment of the present disclosure.

Fig. 5 illustrates an example embodiment of a global namespace identifier, according to an example embodiment of the present disclosure.

Fig. 6 illustrates a first embodiment of a path for processing a namespace identifier, according to an example embodiment of the present disclosure.

Fig. 7A illustrates a first operation of a second embodiment of a path for processing a namespace identifier, according to an example embodiment of the present disclosure.

Fig. 7B illustrates a second operation of a second embodiment of a path for processing a namespace identifier, according to an example embodiment of the present disclosure.

Fig. 8 illustrates an embodiment of a function identifier scheme for a device according to an example embodiment of the present disclosure.

Fig. 9 illustrates an embodiment of a namespace identifier mapping scheme, according to an example embodiment of the present disclosure.

Fig. 10 illustrates an embodiment of a migration scheme according to an example embodiment of the present disclosure.

Fig. 11 illustrates a first embodiment of a data protection scheme for data transfer operations according to an example embodiment of the present disclosure.

Fig. 12 illustrates a second embodiment of a data protection scheme for data transfer operations according to an example embodiment of the present disclosure.

Fig. 13 illustrates a third embodiment of a data protection scheme for data transfer operations according to an example embodiment of the present disclosure.

Fig. 14 illustrates a fourth embodiment of a data protection scheme for data transfer operations according to an example embodiment of the present disclosure.

Fig. 15 illustrates a fifth embodiment of a data protection scheme for data transfer operations according to an example embodiment of the present disclosure.

Fig. 16 illustrates a sixth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure.

Fig. 17 illustrates a seventh embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure.

Fig. 18 illustrates an eighth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure.

Fig. 19 illustrates a ninth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure.

Fig. 20 illustrates a tenth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure.

Fig. 21 illustrates an eleventh embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure.

Fig. 22 illustrates a twelfth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure.

Fig. 23 illustrates a thirteenth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure.

Fig. 24 illustrates a fourteenth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure.

Fig. 25 illustrates a fifteenth embodiment of a data protection scheme for data transfer operations according to an example embodiment of the present disclosure, which shows some example implementation details.

Fig. 26 illustrates a sixteenth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure.

Fig. 27 illustrates an embodiment of a data protection scheme for data transfer operations in which device function circuitry may modify data, according to an example embodiment of the present disclosure.

FIG. 28 illustrates an embodiment of a method for data protection for controller state migration operations, according to an example embodiment of the present disclosure.

FIG. 29 illustrates an embodiment of a method for data protection for data migration operations, according to an example embodiment of the present disclosure.

Fig. 30 illustrates an example embodiment of a user device according to an example embodiment of the present disclosure.

Fig. 31 shows an example embodiment of an apparatus according to an example embodiment of the present disclosure.

FIG. 32 illustrates an embodiment of a method for accessing a namespace in accordance with an example embodiment of the present disclosure.

Fig. 33 illustrates an embodiment of a method for protecting data for a data transfer operation according to an example embodiment of the present disclosure.

Detailed Description

Devices such as storage devices, computing devices, and/or the like may use namespaces to refer to a collection of one or more resources such as storage resources, computing resources, memory resources, and/or the like. The namespaces can enable a user, such as a host, another device, a program, an operating system, and/or the like, to access a set of one or more resources as a unit, which can be logically separate, individually addressable, and/or the like, for example.

The namespace identifier can be used to identify a namespace such that the namespace can be created, configured, assigned, attached, accessed, deleted, and/or the like. For example, the host may write data to a storage namespace in the storage device by sending a write command to the storage device, the write command including a namespace identifier for identifying the storage namespace in which the data is to be stored. Depending on implementation details, the storage namespaces (and/or the resources referenced by the storage namespaces) may appear to the host as separate logical storage devices within the one or more physical storage devices.

The namespaces and/or namespace identifiers can be used in different contexts. For example, a Virtual Machine (VM) running on a host may be configured to access a relatively small number of storage namespaces located on one or more storage devices. Instead, a Virtual Machine Manager (VMM) may manage multiple virtual machines and a relatively large number of storage namespaces, which may be configured across one or more storage devices, chassis, servers, racks, data centers, and/or the like. As another example, a virtual machine may be configured to access a namespace using a single controller at a device, while a virtual machine manager may manage different virtual machines that may be configured to access different namespaces using one or more controllers at one or more devices. As yet another example, a child controller at a device may be configured to access one or more namespaces of a single subsystem (e.g., NVM subsystem) and/or a single user (e.g., virtual machine), while a parent controller at a device may interact with one or more namespaces of one or more subsystems (e.g., NVM subsystem), one or more users, virtual machine manager, and/or the like.

Some aspects of the present disclosure relate to namespace identification of devices. For example, according to example embodiments of the present disclosure, one or more characteristics of the namespace identifier may be based on the context in which the namespace identifier may be used. For example, the virtual machine manager may use a relatively large (e.g., 64-bit) namespace identifier to enable the virtual machine manager to manage a relatively large number of namespaces for multiple virtual machines. Instead, virtual machines managed by the virtual machine manager may use a relatively small number of namespaces that may be represented by relatively small (e.g., 2-bit) namespace identifiers. However, depending on implementation details, the use of relatively large namespace identifiers by virtual machines may result in inefficient use of resources such as memory space, bandwidth, processing power, and/or the like. Thus, according to example embodiments of the present disclosure, one user (e.g., a virtual machine manager) may identify a namespace using a relatively large namespace identifier, a portion thereof, a compressed version thereof, and/or the like, while another user (e.g., a virtual machine) may identify the same namespace using a relatively smaller namespace identifier or a portion thereof, a compressed version thereof, and/or the like.

As another example, in some namespace identifier schemes according to example embodiments of the present disclosure, namespaces may be identified by different namespace identifiers and/or different types of namespace identifiers based on the types of controllers that may be used to access the namespaces. For example, in some embodiments, a first controller (e.g., a child controller) may perform a first access to a namespace using a first namespace identifier (e.g., a local namespace identifier) and a second controller (e.g., a parent controller) may perform a second access to the namespace using a second namespace identifier (e.g., a global namespace identifier). Additionally or alternatively, the controller may reference namespaces using different namespace identifiers and/or different types of namespace identifiers based on the operating mode of the controller. For example, the controller may operate in a first mode (e.g., a reduced privilege mode) in which the controller may identify the namespace using a first namespace identifier (e.g., a local namespace identifier) and/or a second mode (e.g., an elevated privilege mode) in which the controller may identify the namespace using a second namespace identifier (e.g., a global namespace identifier).

In some embodiments, the second namespace identifier may include information for determining the first namespace identifier. For example, the first namespace identifier can be encoded in the second namespace identifier, embedded in the second namespace identifier, and/or the like. Additionally or alternatively, the second namespace identifier can include information identifying the means (e.g., controller, device, port, and/or the like) in which the namespace can be implemented. For example, in embodiments in which the first namespace identifier may be implemented with a local namespace identifier, the second namespace identifier may include a local namespace identifier concatenated with a controller identifier for a controller that may implement the namespace and/or a port identifier for a device port with which the controller may communicate.

In some namespace identifier schemes according to example embodiments of the present disclosure, different communication paths may be used to perform input and/or output (I/O or IO) operations for namespaces using different types of controllers, different namespace identifiers, and/or different types of namespace identifiers, and/or the like. For example, in some embodiments, a child controller may use a local namespace identifier received in an IO queue to access a namespace attached to the child controller. As another example, in some embodiments, a parent controller may access a namespace attached to the parent controller using a local namespace identifier received in an IO queue, while the parent controller may access a namespace attached to a child controller using a global namespace identifier received in a management queue. As yet another example, in some embodiments, a parent controller may use one or more global namespace identifiers received in one or more IO queues to access one or more namespaces attached to child and/or parent controllers. In some embodiments, a controller that uses a global namespace identifier received in an IO queue may use a namespace processing path that may be implemented at least in part using hardware acceleration.

Some additional aspects of the present disclosure relate to data protection for data transfer operations. For example, a device may include a first controller configured to receive data (e.g., from a user such as a host), generate data (which may be referred to as protected data) that may be protected with a protection scheme based on the received data (e.g., using encryption), and write the protected data to device functional circuitry (e.g., one or more storage resources, computing resources, memory resources, network resources, and/or the like). The device may also include a second controller configured to read the protected data from the device functional circuitry, generate plaintext data from the protected data (e.g., using decryption), and transmit the plaintext data from the device (e.g., to the host).

However, sending plaintext (e.g., unprotected) data from a device may create a security risk. For example, the first device may send migration data, such as user data, controller metadata, and/or the like, to the second device as part of a migration operation to migrate programs, virtual machines, physical machines, operating systems, and/or the like to different locations. However, if the first device sends the migration data in plain text (e.g., unprotected), the plain text data may be used for unauthorized purposes by one or more hosts, virtual machines, virtual machine managers, hypervisors, additional devices, and/or the like located between the first device and the second device.

In a data protection scheme according to example embodiments of the present disclosure, a controller may transmit data from a device in a protected form. For example, a parent controller at the source device may send migration data in a protected (e.g., encrypted) form to the target device as part of the migration operation.

In some embodiments, the migration data may be converted to a protected form at least in part by another device at the apparatus. For example, a child controller at a source device may encrypt user data that a parent controller at the source device may send to a target device in encrypted form. Additionally or alternatively, migration or other data may be converted into a protected form by a separate processor, encryption engine, and/or the like at the device.

In some embodiments, the migration data may be converted to a protected form at least in part by a controller that may send the migration data. For example, a parent controller at the source device may encrypt the child controller metadata and send the child controller metadata to the target device in encrypted form. In some embodiments, the target device may decrypt and/or use the sub-controller metadata, e.g., to configure the sub-controller at the target device.

In some embodiments, and depending on implementation details, transmitting data, such as migration data, from a device in a protected form may reduce or eliminate one or more security risks. In addition, some embodiments may utilize existing protected (e.g., encrypted) resources. For example, the device may include existing cryptographic resources that the sub-controller may use to write protected user data to the device function circuitry. The parent controller may send the already encrypted user data as part of the migration operation. Thus, depending on implementation details, the migration data may be sent in protected form without involving additional protected (e.g., encrypted) resources.

The present disclosure encompasses many aspects related to namespaces and namespace identifiers of devices, protection schemes for data transfer, and/or the like. The aspects disclosed herein may have independent utility and may be embodied separately, and not every embodiment may utilize every aspect. In addition, these aspects may also be embodied in various combinations, some of which may synergistically amplify some of the benefits of the various aspects.

For purposes of explanation, some example embodiments may be described in the context of some specific implementation details. For example, some embodiments may be described in terms of: users implemented with virtual machines and/or virtual machine managers, devices implemented with storage devices, resources configured as namespaces, namespaces implemented with nonvolatile memory express (NVMe) namespaces, controllers implemented with protocol controllers such as NVMe controllers, controllers implemented within peripheral component interconnect express (PCIe) functionality, operations implemented in the context of migration (e.g., live migration), and/or the like. As another example, some embodiments may be described in the context of a migration operation. However, aspects of the disclosure are not limited to these or any other implementation details. For example, in some embodiments, the controller may be implemented within one or more network endpoints in lieu of or in addition to one or more PCIe functions. As another example, in some embodiments, a namespace may not be used to configure device capabilities (e.g., compute storage and/or computing functions, store Local Memory (SLM) and/or the like). As another example, one or more device resources may be implemented, for example, with one or more capabilities such as compression (e.g., compression in a Data Processing Unit (DPU) as the data passes through the DPU), computing storage and/or computing functions, storing Local Memory (SLM), and/or the like.

Fig. 1 illustrates an embodiment of a system with a namespace identifier, according to an example embodiment of the present disclosure. The system shown in fig. 1 may include at least one host 102 and at least one device 104 that may communicate using a communication fabric 103. One or more virtual machines 106 (identified as VM1, VM2, …) may run on the host 102. One or more virtual machine managers (e.g., hypervisors) 108 may run on the host 102 and manage one or more virtual machines 106.

The device 104 can include one or more resources 110 (e.g., storage resources, computing resources, memory resources, and/or the like). One or more namespaces 112 (identified as NS a through NS F) can be configured to reference one or more sets of resources 110. One or more namespaces 112 can be identified by one or more corresponding namespaces identifiers (NSIDs) 114.

The device 104 may also include one or more controllers 116A, 116B, … (which may be individually and/or collectively 116). In the embodiment shown in fig. 1, one or more controllers 116 may include one or more parent controllers 116A and/or one or more child controllers 116B (identified as child controllers 1 and/or 2). The controller 116 may be configured as an interface between the host 102 (e.g., one or more virtual machine managers 108 and/or one or more virtual machines 106) and one or more namespaces 112. As described below, the controller 116 may be implemented as, for example, PCIe functions, software threads, and/or the like. For example, the controller 116 may be coupled to the user (e.g., host 102, virtual machine 106, virtual machine manager 108, and/or the like) by being assigned to the user using a protocol such as NVMe (which may use an underlying communication connection such as PCIe, ethernet, and/or the like). In some embodiments where PCIe may be used as the underlying transport, the controller 116 may be a PCIe function. The one or more controllers 116 may be configured with individual connections (e.g., one-to-one connections) to one or more users (e.g., hosts 102, virtual machines 106, virtual machine manager 108, and/or the like). Additionally or alternatively, one or more controllers 116 may share a connection to a user, one or more users may share a connection to a controller 116, or the controller 116 and user may be connected in any other configuration. In some embodiments, the controller 116 may provide access to one or more namespaces 112 (e.g., using one or more namespace identifiers 114 to identify one or more corresponding namespaces 112) to the host 102 (e.g., one or more virtual machine managers 108 and/or one or more virtual machines 106).

In some embodiments, the use of the namespace 114 may enable the virtual machine manager 108 and/or virtual machine 106 running on the host 102 to access the namespace 112 as a unit, which may be logically separate, individually addressable, and/or the like, for example. Depending on implementation details, the namespace 112 (and/or the resources referenced by the namespace) may appear to the host 102 as a separate logical storage device within the physical storage device 104. Depending on implementation details, the use of namespaces may provide isolation between resources in different namespaces, e.g., to provide and/or maintain isolation between virtual machines 106.

In some embodiments, the namespaces 112 can be configured to reference resources 116 in more than one device 102 (e.g., multiple namespaces in more than one device 102 are configured to appear (e.g., act as) one storage space). For example, in some embodiments, the logical NVMe namespace may be implemented using software on a host computer that may be configured with one or more network connections to one or more additional host devices (e.g., host chassis). One or more (e.g., each) of the host devices may include one or more additional host processors, storage devices, and/or the like, which may be implemented, for example, with NVMe protocols. In such embodiments, the host software implementation may have a namespace. Depending on implementation details, the host software implementation may execute one or more services (e.g., a background service), which may include accessing one or more physical NVMe drivers that may have one or more internal namespaces that may be hidden from end clients that may access the one or more services. As another example, in some embodiments, the host software implementation described above may be partially or entirely implemented in hardware, e.g., using a DPU.

In some embodiments, one or more resources in one namespace 112 may overlap with one or more resources in another namespace 112. In some embodiments, virtual machine manager 108 and/or virtual machine 106 may interface with more than one controller 116. In some embodiments, the controller 116 may interface with more than one virtual machine manager 108 and/or virtual machine 106.

In some embodiments, the namespaces 112 can be implemented as private namespaces that can be accessible (e.g., only accessible) by the corresponding controllers 116, virtual machines 106, and/or the like. In some embodiments, the namespaces 112 can be implemented as shared namespaces that can be accessible by one or more controllers 116, virtual machines 106, and/or the like. In some embodiments, private namespaces may be configured, implemented, enforced, and/or the like using a namespace data structure that may include portions for indicating the state (e.g., private, shared, and/or the like) of the namespaces. For example, namespaces can be managed using one or more commands (e.g., from a host) such as create, modify, delete, attach, detach, and/or the like, which can use a namespace data structure to indicate whether the namespaces are private, read-only, shared, and/or the like. In some embodiments, one or more IO commands may access a particular namespace based on the state of one or more portions of the namespace data structure.

Although the system shown in fig. 1 is not limited to any particular implementation details, in some embodiments, one or more components, operations, and/or the like may be implemented at least in part using a protocol such as NVMe. For example, the parent controller 116A may be implemented with an NVMe master controller and the child controller 116B may be implemented with an NVMe slave controller (e.g., a slave controller associated with the master controller used to implement the parent controller 116A). As another example, the namespace 112 can be implemented with one or more NVMe storage namespaces, computing namespaces, memory namespaces, and/or combinations thereof. As another example, one or more controllers 116 and/or one or more corresponding namespaces 112 can be configured as NVM subsystems. For example, in embodiments implemented at least in part with NVMe, one or more controllers 116, one or more corresponding namespaces 112, one or more ports of communication framework 105, and/or the like can be implemented with a derived NVM subsystem, which can be configured, for example, using one or more resources from an underlying NVM subsystem. In such embodiments, the parent controller may enable the host to create one or more namespaces (e.g., an underlying namespace) and/or map one or more underlying namespaces (e.g., to one or more export namespaces in the export NVM subsystem).

In some embodiments, the communication framework 105 may be used to implement at least a portion of the communication structure 103 and/or one or more components (e.g., communication endpoints), operations, and/or the like of the at least one device 104 shown in fig. 1. For example, at least a portion of the communication fabric 103 may be implemented with one or more PCIe interconnects, interfaces, and/or the like. In such embodiments, one or more controllers 116 may be implemented with one or more PCIe functions. For example, the parent controller 116A may be implemented with PCIe physical or virtual functions and the child controller 116B may be implemented with PCIe physical or virtual functions. In some example embodiments, the parent controller 116A may be implemented with a PCIe physical function (e.g., PF 0) and the child controller 116B may be implemented with a virtual function (e.g., VF 1) associated with the physical function used to implement the parent controller 116A. In some example embodiments, the parent controller 116A may be implemented with a PCIe physical function (e.g., PF 0), and the child controller 116B may be implemented with a different physical function (e.g., PF 1).

As another example, at least a portion of communication fabric 103 may be implemented with a network fabric such as ethernet, fibre channel, infiniband, and/or the like. In embodiments implemented at least in part with a network architecture, one or more controllers may be implemented at least in part with network endpoints.

In some embodiments, there may not be a one-to-one correspondence (e.g., alignment) between one or more of the components, operations, and/or the like shown in fig. 1 and the implementation technology. For example, in some embodiments, the controller 116 may be implemented with more than one NVMe controller, PCIe functions, network endpoints, and/or the like. As another example, in some embodiments, NVMe controllers, PCIe functions, network endpoints, and/or the like may be used to implement more than one controller 116.

The parent controller and/or child controller may have one or more (but not necessarily any) of the following characteristics, implement one or more (but not necessarily any) of the following features, and/or the like.

In some embodiments, and depending on implementation details, a parent controller may allocate, attach, manage, and/or the like one or more resources of a child controller. For example, a parent controller (e.g., a controller implemented at least in part with an NVMe master controller) can allocate, attach, manage, and/or the like one or more queue resources (e.g., virtual queue resources for managing commit queues, completion queues, and/or the like), interrupt resources (e.g., virtual interrupt resources), and/or the like to a child controller (e.g., a controller implemented at least in part with an NVMe slave controller). As another example, a parent controller (e.g., a controller implemented at least in part with PCIe physical functionality) may initially control (e.g., own or occupy) one or more physical resources, such as memory, I/O resources (e.g., access to network ports), queues, and/or the like. The parent controller may manage and/or communicate one or more of the physical resources for the child controllers (e.g., controllers implemented at least in part with PCIe virtual functions).

In some embodiments, and depending on implementation details, a parent controller may perform one or more management functions of a child controller. For example, a parent controller may receive and/or execute management commands (e.g., from a host), e.g., to create, configure, allocate, attach, map, delete, and/or the like, one or more namespaces.

In some embodiments, and depending on implementation details, a parent controller may have greater visibility and/or greater privileges than a child controller. For example, a child controller may be able to receive and/or use (e.g., only receive and/or use) local namespace identifiers, while a parent controller may be able to receive and/or use global namespace identifiers (e.g., using a mapping of one or more global namespace identifiers to one or more local namespace identifiers and/or child controllers). As another example, a parent controller may have one or more privileges to perform migration (e.g., live migration) of NVM namespaces (e.g., from a first controller and/or NVM subsystem to a second controller and/or NVM subsystem).

Any of the hosts disclosed herein, including host 102 shown in fig. 1, may be implemented with any component or combination of components, including one or more of a client device, a server, a storage node, a CPU, a personal computer, a tablet computer, a smart phone, and/or the like.

Any communication connections, interfaces, protocols, structures, frameworks, controllers, functions, endpoints, and/or the like disclosed herein, including communication structure 103 and/or framework 105 shown in fig. 1, may be implemented, for example, with, for example, the following: PCIe, NVMe, architecturally NVMe (NVMe-orf), ethernet, transmission control protocol/internet protocol (TCP/IP), direct Memory Access (DMA) Remote DMA (RDMA), converged RDMA over ethernet (ROCE), fibre channel, infiniband, serial ATA (SATA), small Computer System Interface (SCSI), serial Attached SCSI (SAS), iWARP, computing fast link (CXL) and/or coherence protocols (such as cxl.mem, cxl.cache, cxl.io and/or the like), gen-Z, open coherence accelerator processor interface (opencaps), cache coherence interconnect for accelerators and/or the like, advanced extensible interface (AXI), any generation wireless network including 2G, 3G, 4G, 5G, 6G and/or the like, any generation Wi-Fi, bluetooth, near Field Communication (NFC) and/or the like, or a combination oF the foregoing.

Any of the devices disclosed herein, including the device 104 shown in fig. 1, may be implemented with a storage device, a computing device (e.g., accelerator), a Network Interface Card (NIC), a memory buffer (e.g., memory expander), and/or the like, or combinations thereof, and the one or more resources 110 may include hardware and/or software resources to implement the primary functions of the device 104.

For example, if device 104 is implemented as a storage device, resource 110 may include a storage medium such as one or more flash memory devices, flash Translation Layers (FTLs), and/or the like. As another example, if device 104 is implemented as a Network Interface Card (NIC), resource 110 may include one or more modems, network interfaces, physical layers (PHYs), medium access control layers (MACs), and/or the like.

As another example, if the device 104 is implemented as an accelerator, the one or more resources 110 may be implemented with one or more computing resources (which may also be referred to as computing resources), which may include one or more computing engines, programs, and/or the like. In some embodiments, the computing engine may include combinational logic, sequential logic, one or more timers, counters, registers, and/or state machines, one or more Complex Programmable Logic Devices (CPLDs), FPGAs, application Specific Integrated Circuits (ASICs), central Processing Units (CPUs), such as Complex Instruction Set Computer (CISC) processors (e.g., x86 processors) and/or Reduced Instruction Set Computer (RISC) processors (such as ARM processors), graphics Processing Units (GPUs), neural Processing Units (NPUs), tensor Processing Units (TPUs), data Processing Units (DPUs), and/or combinations thereof.

In some embodiments, a namespace may refer to any device resource 110 that may be implemented with a device 104. For example, a storage namespace may refer to a collection of one or more Logical Block Addresses (LBAs), physical Block Addresses (PBAs), nonvolatile memory devices, cylinders, tracks, channels, pages, and/or the like. As another example, a computing namespace may refer to a collection of one or more computing engines, programs, and/or the like. As another example, a memory namespace may refer to a set of one or more addresses, address ranges, and/or the like of memory units, rows, columns, bytes, words, pages, blocks, and/or the like.

Any of the devices disclosed herein that may be implemented as a storage device may be implemented as any type of non-volatile storage medium based on solid state media, magnetic media, optical media, and/or the like. For example, in some embodiments, the storage device may be implemented as a non-AND (NAND) flash based SSD, a persistent memory such as a cross-grid non-volatile memory, a memory with a change in bulk resistance, a Phase Change Memory (PCM), and/or the like, or any combination thereof.

Any of the devices disclosed herein, including the device 104 shown in fig. 1, may be implemented in any form factor (such as 3.5 inches, 2.5 inches, 1.8 inches, m.2, enterprise and data center standard form factor (EDSFF), NF1, and/or the like) using any connector configuration (such as serial ATA (SATA), small Computer System Interface (SCSI), serial Attached SCSI (SAS), U.2, and/or the like). Any of the devices disclosed herein may be implemented in whole or in part with and/or used in conjunction with a server chassis, a server rack, a data market, a data center, an edge data center, a mobile edge data center, and/or any combination thereof.

In some embodiments, at least one device 104 may be implemented with multiple devices. For example, in some embodiments, resource 110 may be implemented with multiple devices. Such embodiments may include a network and/or interconnection switch and/or an intermediate processor between the communication framework 105 and the resources 110 that may route access to the resources to multiple devices. In such embodiments, the namespace may be configured to include one or more resources on one device and/or on multiple devices. In such embodiments, one or more of the controllers 116 may be implemented, for example, with a network and/or interconnect switch, endpoint, and/or the like. In such embodiments, one or more of the controllers 116 may be implemented with a Data Processing Unit (DPU) (e.g., with single root IO virtualization (SR-IOV)).

In some embodiments, one or more of the hosts 102 and/or controllers 116 may be implemented with one or more software threads. For example, in some embodiments, one or more (e.g., each) of the hosts 102 and/or controllers 116A and/or 116B may be implemented with one or more software threads (e.g., one thread per controller) on one or more processors. In such embodiments, one or more threads may implement internal and/or external communications using a protocol such as NVMe. In some such embodiments, one or more of the controllers 116 may be implemented as a simulation controller.

In any of the embodiments disclosed herein, as shown in fig. 1, one or more components (e.g., one or more hosts) can communicate with one or more other components (e.g., one or more devices) using one or more communication structures 103, frameworks 105, and/or the like.

Fig. 2 illustrates an embodiment of a first namespace access scheme using a namespace identifier, according to an example embodiment of the present disclosure. The embodiment shown in fig. 2 may be implemented, for example, using the embodiment shown in fig. 1, wherein like elements may be referred to by and/or include like numerals, letters, and/or the like.

The embodiment shown in fig. 2 may include a host 202 and a device 204, and the host 202 and the device 204 may communicate using a communication structure and/or communication framework such as that shown in fig. 1. The device 204 may include one or more namespaces 212, some examples of which are shown as namespace 1, namespace 2, …. Virtual machine 206 running on host 202 may be configured to access namespace 1 using sub-controller 216B, as indicated by arrow 218. In some embodiments, the sub-controller 216B may be described as being assigned to the virtual machine 206. In some embodiments, namespace 1 may be described as attached to sub-controller 216B. For purposes of illustration, namespace 1 may be implemented as a storage namespace (e.g., using one or more storage resources), but aspects of the disclosure may be applied to any type(s) of namespace(s).

Depending on implementation details, the sub-controller 216B and/or the namespace 1 may be configured to appear as a separate logical device (e.g., a logical storage device). For example, the sub-controller 216B and/or namespace 1 may be configured as an NVM subsystem. Furthermore, namespace 1 can be implemented as a private namespace, at least from the perspective of virtual machine 206, depending on implementation details.

Thus, virtual machine 206 may be configured to run one or more operating systems, applications, services, programs, and/or the like, and store user data in namespace 1, at least from the perspective of virtual machine 206, namespace 1 may appear to be a separate logical storage device that may be isolated from one or more other resources of device 204. Thus, depending on implementation details, virtual machine 206 may not be aware of one or more other controllers 216, namespaces 212, and/or the like at device 204.

In some embodiments, the sub-controller 216B may have relatively limited visibility (e.g., may only be able to see and/or access a namespace attached to the sub-controller 216B). Thus, virtual machine 206 may use local namespace identifier 214B (which may be referred to as a local namespace ID or a local NSID) to indicate to child controller 216B that virtual machine 206 is accessing namespace 1. Further, because virtual machine 206 may be restricted to accessing a relatively small number of namespaces 212 attached to sub-controller 216B, the local namespace identifier may be implemented with a relatively small identifier (e.g., relatively few bits). For example, in some embodiments, sub-controller 216B may use a Local namespace identifier that may include two bits to identify up to four namespaces that may be attached to sub-controller 216B (e.g., local namespace identifier local_ns_1 (binary value 00) may identify namespace 1, local namespace identifier local_ns_2 (binary value 01) may identify namespace 2, local namespace identifier local_ns_3 (binary value 10) may identify namespace 3, and/or local_ns_4 (binary value 11) may identify namespace 4).

Although the child controller 216B may receive the local namespace identifier 214B from the virtual machine 206 to identify a namespace accessed by the virtual machine 206, the device 204 may include one or more namespaces 212 that the child controller 216B may not have access to. Thus, in some embodiments, the sub-controller 216B may translate the local namespace identifier 214B received from the virtual machine 206 into an internal namespace identifier 219-1, the internal namespace identifier 219-1 may enable an interface to internal resources within the device 204 (e.g., in the case of a storage device, a non-volatile memory interface such as a Flash Translation Layer (FTL), a channel controller, and/or the like) to distinguish namespaces 212 that may be attached to different controllers 216. Examples of internal namespace identifiers may include global namespace identifiers (e.g., child controller 216B may reconstruct global namespace identifiers from local namespace identifiers), physical namespace identifiers, underlying namespace identifiers, and/or the like, as described below. In some embodiments, the internal namespace identifier 219-1 may be implemented, for example, with a compressed namespace identifier that may reduce the bit width of the identifier to reduce power consumption, circuit area, latency, and/or the like.

In some embodiments, the device 204 shown in fig. 2 may include one or more additional sub-controllers 216B that may be assigned to one or more additional virtual machines 206 running on the host 202. If one or more additional sub-controllers 216B are configured in a manner similar to the sub-controllers 216B shown in fig. 2 (e.g., each sub-controller 216B is assigned to a corresponding virtual machine 206), the sub-controllers 216B may use overlapping Local namespace identifiers (e.g., each sub-controller 216B may use local_ns_1 (binary value 00) to local_ns_4 (binary value 11)) to identify the underlying namespaces to which they are each attached at the device 204 because the combination of the particular sub-controller 216B (which may be attached to the virtual machine 206) and the Local namespace identifier 214B may uniquely identify the underlying namespaces at the device 204 (e.g., using the internal namespace identifier 219-1).

Virtual machine manager 208 running on host 202 may be configured to access namespace 1 using parent controller 216A, as indicated by arrow 220. However, the parent controller 216A may be associated with multiple child controllers 216B, some of which child controllers 216B may use overlapping local namespace identifiers to identify their respective attached namespaces (e.g., each of the associated child controllers 216B may use local namespaces numbered 1-4). Thus, virtual machine manager 208 may not be able to identify a particular namespace 212 (e.g., namespace 1) to parent controller 216A using only local namespace identifier 214B.

In some embodiments, the parent controller 216A may be placed in a mode in which the parent controller 216A may perform the migration operation of the child controller 216B. In this mode, the parent controller 216A may use the local namespace identifier 214B, for example, during all or a portion of the operations of the child controller 216B. In this mode, parent controller 216A may decode, for example, local namespace identifier 214B received from virtual machine manager 208 to reference the child controller 216B that is being migrated.

In the embodiment shown in FIG. 2, virtual machine manager 208 may use global namespace identifier 214A to identify namespace 1 to parent controller 216B. In some embodiments, and depending on the context, the global namespace identifier may include first information that may identify the namespace and second information that may identify the context of the namespace. For example, in the embodiment shown in FIG. 2, global namespace identifier 214A may include first information that may identify namespace 1 and second information that may identify sub-controller 216B to which namespace 1 may be attached. In some embodiments, the second information that may identify a broader context of the namespace may include information that may identify a port through which the namespace may communicate, a subsystem in which the namespace may be used (e.g., NVM subsystem), a device, a system, a chassis, a server, a rack, a data center, etc., and/or the like. In some embodiments, and depending on the context, the global namespace identifier may be unique, for example, within a subsystem (e.g., NVM subsystem), device, system, chassis, server, rack, data center, and/or the like in which the namespace may be used.

In some example embodiments, the global namespace identifier 214A may include a local namespace identifier 214B concatenated with a controller identifier 217B (which may be referred to as a controller ID) that may identify the child controller 216B. In some example embodiments, the global namespace identifier 214A may include a local namespace identifier 214B concatenated with a controller identifier 217B and a port identifier (e.g., port number) through which the controller may communicate. In some other example embodiments, the first information for identifying the namespace and the second information for identifying a broader context in which the namespace may be used may be combined, encoded, and/or the like to create the global namespace identifier 214A. For example, in some embodiments, the local namespace identifier 214B and the controller identifier 217B can be combined using an encoding algorithm to generate the compressed global namespace identifier 214A.

In the embodiment shown in fig. 2, sub-controller 216B may be identified as controller 1 by controller identifier 217B. Accordingly, namespace 1 can be identified by Global namespace identifier 214A as global_ns_1, and Global namespace identifier 214A can implement global_ns_1 as a concatenation of Local namespace identifiers (e.g., local_ns_1) and Controller identifiers 217B (e.g., controller ID).

Thus, when virtual machine manager 208 accesses namespace 1 using parent controller 216A, virtual machine manager 208 can identify namespace 1 using Global namespace identifier Global_NS_1.

In embodiments in which internal namespace identifier 219-1 is implemented with Global namespace identifier 214A, parent controller 216A may simply use Global namespace identifier 214A (e.g., global_NS_1) received from virtual machine controller 208 as internal namespace identifier 219-1. However, in other embodiments, parent controller 216A may convert global namespace identifier 214A received from virtual machine controller 208 into a format for internal namespace identifier 219-1 (e.g., physical namespace identifier, underlying namespace identifier, compressed namespace identifier, and/or the like).

In embodiments in which device 204 may be implemented with a storage device, one or more child controllers 216B, one or more namespaces 212, and/or one or more parent controllers 216A may be configured, at least in part, as one or more NVM subsystems. For example, the child controller 216B, the namespace 212, and/or the parent controller 216A may be configured as NVM subsystems. As another example, parent controller 216A may be configured as part of an underlying NVM subsystem and child controller 216B and namespace 1 may be configured as part of a derived NVM subsystem that may be derived from the underlying NVM subsystem.

In some embodiments of data transfer (e.g., migration) operations, parent controller 216A may be placed in a mode (e.g., a migration mode based on commands received from a host) in which parent controller 216A may use a Local namespace (e.g., local_ns_1) for one or more (e.g., all) requests for the duration of the transfer operation.

In the embodiment shown in fig. 2, host 202 and device 204 may communicate using a communication structure, framework, and/or the like, as described with respect to the embodiment shown in fig. 1. For example, in some embodiments, the host 202 and the device 204 may communicate using a PCIe fabric, and one or more of the child controllers 216B and/or parent controllers 216A may be implemented at least in part with PCIe functionality (e.g., the parent controller 216A as a physical function and the child controller 216B as a virtual function associated with the physical function, such as may be implemented with single-root IO virtualization (SR-IOV), for example. In such an embodiment, the controller identifier 217B may be implemented as a function identifier (function ID). Examples of function identifiers may include a Universally Unique Identifier (UUID) and/or other numbers such as assigned by a host, enumeration of functions such as assigned by a storage device, and/or the like.

As another example, the host 202 and the device 204 may communicate using a network fabric, and one or more of the child controllers 216B and/or the parent controllers 216A may be implemented at least in part with network endpoints. Although one or more child controllers 216B, parent controllers 216A, namespaces 212, and/or the like may be shown in fig. 2 as being within device 204, in other embodiments, one or more of these components may be located in one or more other devices, chassis, systems, racks, servers, data centers, and/or the like.

Virtual machine manager 208 can access namespace 1, e.g., for the purpose of migrating user data stored in namespace 1 to a different namespace, subsystem (e.g., a VM subsystem), device, and/or the like, as part of a process (e.g., controlled by virtual machine manager 208) to migrate virtual machine 206 to a different virtual machine, hypervisor, host, and/or the like. For example, virtual machine manager 208 can read user data stored in namespace 1 and, once virtual machine 206 is migrated to a different location, transfer the user data to a different namespace that can be used by virtual machine 206 (e.g., user data stored in namespace 1 can be transferred to a different namespace in the same or a different subsystem (e.g., NVM subsystem), device, port, chassis, server, chassis, data center, and/or the like). (in the context of migration, virtual machine manager 208 may alternatively be referred to as a migration server, and/or controller 216A may alternatively be referred to as a migration controller

Fig. 3 illustrates an embodiment of a second namespace access scheme using a namespace identifier, according to an example embodiment of the present disclosure. The embodiment shown in fig. 3 may include one or more elements (e.g., components, operations, and/or the like) similar to elements in the embodiment shown in fig. 1 and/or 2, where similar elements may be indicated by and/or include the same reference numerals, letters, and/or the like. The embodiment shown in fig. 3 may include a host 302 and/or a device 304, which host 302 and/or device 304 may communicate using a communication structure and/or a communication framework such as that shown in fig. 1.

In some aspects, the embodiment shown in fig. 3 may operate in a manner similar to the embodiment shown in fig. 2. For example, in the embodiment shown in FIG. 3, virtual machine manager 308 and parent controller 316A may be configured to access first namespace 312 (identified as namespace 1 and attached to child controller 316B) using Global namespace identifier 314A (identified as Global_NS_1) in a manner similar to that described above with respect to FIG. 2, as indicated by arrow 320.

However, in the embodiment shown in FIG. 3, virtual machine manager 308 and parent controller 316A may also be configured to access another namespace 312 (identified as namespace 5 and attached to parent controller 316A) using another Local namespace identifier 314B (identified as local_NS_5), as indicated by arrow 322.

In some embodiments, as described above with respect to FIG. 2, the child controller 316B and the parent controller 316A may convert the Local namespace identifiers local_NS_1 and local_NS_5 to the internal namespace identifiers 319-1 and 319_5, respectively. If the internal namespace identifier 319-1 is implemented with a Global namespace identifier, the parent controller 316A can use the Global namespace identifier Global_NS_1 as the internal namespace identifier 319-1. Alternatively or additionally, parent controller 316A may convert Global namespace identifier Global_NS_1 to another format for internal namespace identifier 319-1.

Virtual machine manager 308 can access namespace 5, for example, for the purpose of migrating user data stored in namespace 1 to namespace 5, as part of a process (e.g., controlled by virtual machine manager 308) of migrating virtual machine 306 to a different virtual machine, hypervisor, host, and/or the like.

In some embodiments (e.g., embodiments using NVMe protocol), parent controller 316A may access namespace 1 using one or more management queues (e.g., management commit and completion queue pairs), while parent controller 316A may access namespace 5 using one or more IO queues (e.g., IO commit and completion queue pairs). In some embodiments, the input and/or output queues may also be referred to as data queues.

In embodiments where the location device 304 may be implemented with a storage device, one or more child controllers 316B, one or more namespaces 312, and/or one or more parent controllers 316A may be configured, at least in part, as one or more NVM subsystems. For example, child controller 316B and namespace 1 can be implemented with a first NVM subsystem and parent controller 316A and namespace 5 can be implemented with a second NVM subsystem. As another example, the child controller 316B, parent controller 316A, namespace 1, and namespace 5 can be implemented with NVM subsystems.

Fig. 4 illustrates an embodiment of a third namespace access scheme using a namespace identifier, according to an example embodiment of the present disclosure. The embodiment shown in fig. 4 may include one or more elements (e.g., components, operations, and/or the like) similar to elements in the embodiments shown in fig. 1, 2, and/or 3, where like elements may be indicated by reference numerals ending in and/or containing the same numbers, letters, and/or the like. The embodiment shown in fig. 4 may include a host 402 and/or a device 404, which host 402 and/or device 404 may communicate using a communication structure and/or a communication framework such as that shown in fig. 1.

In some aspects, the embodiment shown in fig. 4 may operate in a manner similar to the embodiment shown in fig. 3. For example, in the embodiment shown in FIG. 4, virtual machine manager 408 and parent controller 416A may be configured to access first namespace 412 (identified as namespace 1 and attached to child controller 416B) using Global namespace identifier 414A (identified as Global_NS_1) in a manner similar to that described above with respect to FIG. 3.

However, in the embodiment shown in FIG. 4, virtual machine manager 408 and parent controller 416A may be configured to access namespace 5 (attached to parent controller 416A) using another Global namespace identifier 414A (identified as Global_NS_5), as indicated by arrow 424. Depending on implementation details, using global namespace identifiers for both namespace 1 (attached to child controller 416B) and namespace 5 (attached to parent controller 416A) may enable parent controller 416A to perform both types of accesses using at least part of the hardware path (e.g., the same hardware acceleration path). Depending on implementation details, using the same hardware path may increase IO speed (e.g., read and/or write speed), reduce latency, reduce power consumption, and/or the like.

In embodiments where internal namespace identifiers 419-1 and 419_5 are implemented with a Global namespace identifier, parent controller 416A may use Global namespace identifiers Global_NS_1 and Global_NS_5 as internal namespace identifiers 419_1 and 419-5, respectively. Alternatively or additionally, parent controller 416A may convert Global namespace identifiers Global_NS_1 and Global_NS_5 into another format for internal namespace identifiers 419-1 and 419_5.

Virtual machine manager 408 can access namespace 5, for example, for the purpose of migrating user data stored in namespace 1 to namespace 5, as part of a process (e.g., controlled by virtual machine manager 408) of migrating virtual machine 406 to a different virtual machine, hypervisor, host, and/or the like.

In some embodiments (e.g., embodiments using NVMe protocol), parent controller 416A may access namespace 1 and/or namespace 5 using one or more management queues (e.g., management commit and completion queue pairs). Alternatively or additionally, parent controller 416A may access namespace 1 and/or namespace 5 using one or more IO queues (e.g., IO commit and completion queue pairs). In embodiments where the namespace 412 can be accessed using a management queue, the namespace 412 can be processed at least partially outside of the hardware acceleration path.

In some embodiments, the type of namespace identifier to be used may be based on the use of one or more types of queues (e.g., the type of namespace identifier to be used may be based on whether the request was submitted using a management queue or IO queue). For example, in some embodiments, the controller may use the management queue to use the global namespace identifier for transactions, while the controller may use the IO queue to use the local namespace identifier for transactions. Some such embodiments may implement one or more checks. For example, in some embodiments, the IO queue may allow (e.g., only allow) access to a particular namespace (e.g., namespace 5) using Local namespace identifier 414B (e.g., local_ns_5). Depending on implementation details, this may provide an additional protective layer. For example, virtual machine manager 408 may not inadvertently (e.g., accidentally) initiate a transaction to the namespace (e.g., namespace 1) of child controller 416B. Additionally or alternatively, a read request for the namespace of child controller 416B (e.g., namespace 1) may be submitted to the management queue (e.g., as a commit queue entry (SQE)) using Global namespace identifier global_ns_1. Such read requests to the commit queue may use a different opcode and/or a different command structure than the existing read command SQE. Different opcodes and/or different command structures may be implemented, for example, with a new Get Log Page (Get Log Page) command.

In embodiments in which the device 404 may be implemented with a storage device, one or more child controllers 416B, one or more namespaces 412, and/or one or more parent controllers 416A may be configured, at least in part, as one or more NVM subsystems. For example, child controller 416B and namespace 1 can be implemented with a first NVM subsystem and parent controller 416A and namespace 5 can be implemented with a second NVM subsystem. As another example, the child controller 416B, parent controller 416A, namespace 1, and namespace 5 can be implemented with NVM subsystems.

In the embodiments shown in fig. 2, 3, and/or 4, namespace 1 may be implemented as a read-only, quasi-private, and/or pseudo-private namespace. For example, namespace 1 may appear or may effectively be a private namespace of a child controller in the sense that only the child controller may be able to write data to namespace 1. However, during a migration operation (e.g., live Migration (LM), where a child controller may continue to operate and perform IO operations on namespace 1 during at least a portion of the migration operation), a parent controller may be able to read the child controller's user data from namespace 1 to copy the user data to a different namespace that may be used by the virtual machine to which the child controller may be attached once the virtual machine is migrated to a different location and the user data is copied to a different namespace. In embodiments implemented at least in part with NVMe, for example, if namespace 1 is attached to a parent controller to enable the parent controller to copy user data from namespace 1 to a different namespace, namespace sharing may be enabled for namespace 1, e.g., as part of a migration operation.

Fig. 5 illustrates an example embodiment of a global namespace identifier, according to an example embodiment of the present disclosure. The global namespace identifier 514A may include first information 526 that may identify a namespace and second information 528 that may identify a context of the namespace. In the example embodiment shown in fig. 5, the first information 526 may include the local namespace identifier 514B and the second information 528 may include the controller identifier 517 and the port identifier 521.

In some embodiments, one or more of the local namespace identifier 514B, the controller identifier 517, and/or the port identifier 521 may be implemented with one or more binary digits. For example, namespace identifier 514B may be implemented with three bits, controller identifier 517 (which may be implemented with a PCIe function identifier, for example) may be implemented with eight bits, and port identifier 521 may be implemented with two bits. However, in other embodiments, a different number of bits may be used, some identifiers may be omitted, more identifiers may be included (e.g., to identify subsystems such as NVM subsystems, devices, and/or the like), empty space may be included between any identifiers, and/or the like. In some embodiments, one or more of namespace identifier 514B, controller identifier 517, and/or port identifier 521 may not be distinct components, but may be combined and/or encoded, for example, as compressed global namespace identifier 514A.

Fig. 6 illustrates a first embodiment of a path for processing a namespace identifier, according to an example embodiment of the present disclosure. The namespace processing path shown in FIG. 6 can be used, for example, by any controller that can receive a local namespace identifier. For example, the namespace processing path shown in FIG. 6 may be used by the sub-controller 216B that may receive the local namespace identifier 214B in FIG. 2 or any other sub-controller disclosed herein.

Referring to FIG. 6, the namespace processing path may receive a namespace identifier 628 (which may be referred to as an external namespace identifier), for example, from a queue 630, which queue 630 may be implemented, for example, with an IO commit queue. In the example shown in fig. 6, for example, the input namespace identifier may include a first portion that may hold the local namespace identifier 614B and a second portion that may include unused data (e.g., padding data such as zeros) 632, so the namespace identifier 628 may have the same length as the global namespace identifier.

The local namespace identifier 614B may be transferred to a build register 634 (e.g., a reconstruction register) where it may be combined (e.g., concatenated) with a Controller Identifier (CID) 617 and/or a Port Identifier (PID) 621 to build (e.g., reconstruct) the global namespace identifier. For example, the namespace processing path shown in FIG. 6 may be used in a sub-controller, which may be aware of its controller identifier 617 (e.g., function identifier) and/or path identifier 621 that it may load into a corresponding portion of the build register 634. In some embodiments, the namespace processing path shown in fig. 6 may perform a check to confirm that unused data (e.g., fill data such as zero) 632 has the expected data pattern. In other embodiments, unused data 632 may be discarded, for example, by masking unused data 632 when local namespace identifier 614B is loaded into build register 634.

In some embodiments, the constructed global namespace identifier 614A may be used directly as the internal namespace identifier 619 (e.g., as the internal namespace identifier 219-1 shown in FIG. 2) as shown by the dashed line 636. In some embodiments, the constructed global namespace identifier 614A may be further processed by a converter 638 (e.g., a converter circuit) to convert it into a different format (e.g., a compressed format) that may be used for the internal namespace identifier 619. In some embodiments, converter 638 and/or a conversion operation may be combined with a construction register 634 and/or a construction operation.

The namespace processing path shown in FIG. 6 may be implemented in hardware, software, or a combination thereof. In some embodiments, implementing the namespace processing path at least partially in hardware may provide relatively high-speed and/or unimpeded processing of the namespace identifier by the controller. For example, some or all of the namespace processing paths can be implemented with combinational logic, sequential logic, one or more timers, counters, registers and/or state machines, one or more Complex Programmable Logic Devices (CPLDs), field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), one or more processors and/or processing units executing instructions stored in any type of memory, or any combination thereof.

Fig. 7A illustrates a first operation of a second embodiment of a path for processing a namespace identifier, according to an example embodiment of the present disclosure. Fig. 7B illustrates a second operation of a second embodiment of a path for processing a namespace identifier, according to an example embodiment of the present disclosure. Fig. 7A and 7B may be referred to individually and/or collectively as fig. 7.

The namespace processing path shown in FIG. 7 can be used, for example, by any controller that can receive local and/or global namespace identifiers. For example, the namespace processing path shown in FIG. 7 may be used by any of the child and/or parent controllers shown in FIG. 2, FIG. 3, and/or FIG. 4 or any other child and/or parent controllers disclosed herein. The namespace processing path shown in FIG. 7 may include one or more elements (e.g., components, operations, and/or the like) similar to elements in the embodiment shown in FIG. 6, where like elements may be referred to by reference numerals ending in and/or containing the same numbers, letters, and/or the like.

Referring to FIG. 7A, a namespace processing path may receive a namespace identifier 728 (which may be referred to as an external namespace identifier), e.g., from a queue 730, which queue 730 may be implemented, e.g., with an IO commit queue. In the example shown in fig. 7, for example, the input namespace identifier may include a first portion that may hold the local namespace identifier 714B and a second portion that may include unused data (e.g., padding data such as zeros) 732, so the namespace identifier 728 may have the same length as the global namespace identifier.

The local namespace identifier 714B can be transferred to a build register 734 (e.g., a reconstruction register) where it can be combined (e.g., concatenated) with the controller identifier 717 and/or the port identifier 721 to build (e.g., reconstruct) the global namespace identifier. For example, the namespace processing path may be used in a sub-controller, which may be aware of its controller identifier 717 and/or path identifier 721 that it may load into the corresponding portion of the build register 734. In some embodiments, the namespace processing path may perform a check to confirm that unused data (e.g., fill data such as zero) 732 has the expected data pattern. In other embodiments, unused data 732 may be discarded, for example, by masking unused data 732 when local namespace identifier 714B is loaded into build register 734.

The namespace processing path shown in FIG. 7 may include a multiplexer 740, for example, where the namespace processing path is configured to receive the local namespace identifier 714B as input, the multiplexer 740 may select the output of the configuration register 734 to be used as the global namespace identifier 714A, as indicated by arrow 742.

Referring to FIG. 7B, one or more operations of the namespace processing path may be similar to those shown in FIG. 7A, however, the namespace processing path may receive the global namespace identifier 714A from the queue 730. Thus, multiplexer 740 may choose to input global namespace identifier 714A for use (e.g., directly) as an internal namespace identifier (e.g., internal namespace identifier 319-1 or 319-5 shown in FIG. 3), as indicated by arrow 744, or as input to converter 738, converter 738 may convert global namespace identifier 714A into a different format that may be used for the internal namespace identifier.

Depending on implementation details, the namespace processing paths shown in fig. 7A and 7B may provide relatively high-speed and/or unimpeded processing of local and/or global namespace identifiers by the controller.

Fig. 8 illustrates an embodiment of a function identifier scheme for a device according to an example embodiment of the present disclosure. The embodiment shown in fig. 8 may be used, for example, with any of the namespace identifiers disclosed herein that may include a function identifier, including the global namespace identifiers described with respect to fig. 2, 3, 4, 5, 6, and/or 7. For purposes of illustration, the embodiment illustrated in FIG. 8 may be described in the context of a device implemented with a PCIe protocol (e.g., using SR-IOV), but aspects of the invention may be applied to any other type of communication protocol.

Referring to fig. 8, device 804 may include a first set of functions 846 configured to communicate using a first port identified as port 0 and a second set of functions 848 configured to communicate using a second port identified as port 1. The first set 846 may include a first physical function identified by the physical function identifier PF0 and any number of virtual functions (which may include, for example, resources transferred from the first physical function) identified by the virtual function identifiers VF0-VF 64. The second set 848 may include a second physical function identified by the physical function identifier PF0 and any number of virtual functions (which may include, for example, resources transferred from the second physical function) identified by the virtual function identifiers VF0-VF 64.

To distinguish between the functions associated with port 0 and port 1, one or more of the physical and/or virtual function identifiers (e.g., each) may be mapped to a corresponding internal function identifier 850, as shown in fig. 8. Accordingly, PF0 in group 846 (associated with port 0) may be mapped to internal function 128, any of VF0-VF64 in group 846 (associated with port 0) may be mapped to internal functions 0-63, respectively, PF0 in group 848 (associated with port 1) may be mapped to internal function 129, and any of VF0-VF64 in group 848 (associated with port 1) may be mapped to internal functions 64-127, respectively.

The internal function identifier 850 may be used, for example, as one or more of the function identifiers, including the global namespace identifiers described with respect to fig. 2, 3, 4, 5, 6, and/or 7. For example, any of the internal function identifiers "internal functions 0-129" may be used as one of the controller identifiers 617 and/or 717 in the embodiments shown in fig. 6 and/or 7, respectively.

In some embodiments, one or more physical functions may be included in one or more of groups 846 and/or 848. In some embodiments, which may be implemented at least in part with NVMe, the primary controller and/or the secondary controller may be implemented with more or less than one function (e.g., physical function and/or virtual function). In some embodiments where storage device 804 may be implemented with two or more ports (e.g., port 0 and port 1), one port may be designated as a primary port and another port may be designated as a secondary port.

In some embodiments, the child controller may operate in a mode in which it may perform one or more operations of the parent controller. In this mode, the sub-controllers may be referred to as boost (e.g., privileged) controllers. In some embodiments, the sub-controllers may temporarily operate as lift controllers, for example, to perform migration such as live migration. The promotion controller may operate with one or more privileges (e.g., any number of privileges of the parent controller described herein), such as the ability to view and/or access one or more namespaces using a global namespace identifier (e.g., the ability to use a mapping of a local namespace identifier across devices to a controller identifier). In some embodiments, the controller may operate in a first mode (e.g., a reduced privilege mode) in which the controller may identify the namespace using a local namespace identifier and/or in a second mode (e.g., an elevated privilege mode) in which the controller may identify the namespace using a global namespace identifier.

Thus, for example, a child controller operating as a lift controller may perform any number of operations of any parent controller described herein (such as parent controllers 216A, 316A, and/or 416A shown in fig. 2, 3, and/or 4, respectively). In some embodiments, for example, a child controller may be promoted by an associated parent controller based on one or more management commands received by the associated parent controller (e.g., from a host, virtual machine manager, and/or the like).

Fig. 9 illustrates an embodiment of a namespace identifier mapping scheme, according to an example embodiment of the present disclosure. The embodiment shown in fig. 9 may be implemented, for example, using the embodiments shown in fig. 1, 2, 3, and/or 4, wherein like elements may be referred to by reference numerals ending in and/or containing the same numbers, letters, and/or the like. The embodiment shown in fig. 9 may include a host 902 and/or a device 904 that may communicate using a communication architecture and/or communication framework such as that shown in fig. 1.

The embodiment shown in fig. 9 may include a host 902 and a device 904. One or more virtual machines 906 (identified as virtual machine 1, virtual machine 2, …) may run on host 902. One or more virtual machine managers (e.g., hypervisors) 908 can run on the host 902 and manage one or more virtual machines 906.

The device 904 may include one or more parent controllers 916A and one or more child controllers 916B (some examples of which are identified as child controller 1 and child controller 2). Device 904 can include one or more namespaces 912 (identified as NS 1-NS 8, which can be configured as part of an underlying subsystem (e.g., NVM subsystem) 952, which underlying subsystem 952 can, for example, serve as a source of physical resources that can be exported to one or more export subsystems (e.g., export NVM subsystem) 954. For example, the underlying namespaces 912 identified as NS1, NS 3, NS 4, and/or NS8 may be exported to the export subsystem 954-1 identified as export subsystem 1, and the export subsystem 954-1 may include the sub-controllers 1 to which the underlying namespaces NS1, NS 3, NS 4, and/or NS8 may be attached. As yet another example, the underlying namespaces 912 identified as NS2, NS 5, NS 6, and/or NS 7 may be exported to export subsystem 954-2 identified as export subsystem 2, and export subsystem 954-2 may include the sub-controllers 2 to which the underlying namespaces NS2, NS 5, NS 6, and/or NS 7 may be attached. The sub-controller 1 may be assigned to the virtual machine 1, and the sub-controller 2 may be assigned to the virtual machine 2.

As described with respect to the embodiment shown in fig. 1, host 902 and device 904 may communicate using a communication structure, framework, and/or the like. For example, in some embodiments, the host 902 and the device 904 may communicate using a PCIe fabric, and one or more of the child controller 916B and/or the parent controller 916A may be implemented at least in part with PCIe functionality (e.g., the parent controller 916A may be implemented as physical functionality, and one or more of the child controller 916B may be implemented as one or more virtual functions associated with the physical functionality). In embodiments implemented at least in part with NVMe, one or more of the underlying NVM subsystem 952 and/or the export subsystem 954 may be implemented as NVM subsystems.

In some embodiments, one or more of the underlying namespaces 912 can use an internal namespace identifier (e.g., a physical namespace identifier that can be implemented and/or referred to as an underlying namespace identifier). To enable one or more of the underlying namespaces 912 to be accessed by the virtual machine 906 using the local namespace identifiers, the embodiment shown in FIG. 9 may map the one or more local namespace identifiers to the one or more underlying namespace identifiers. In some embodiments, the mapping may be implemented, at least in part, using one or more mapping data structures, such as mapping table 956 shown in fig. 9.

For example, mapping table 956-1 in export subsystem 954-1 may indicate that the underlying namespaces NS1, NS 3, NS 4, and/or NS 8 may be mapped to local namespaces identifiers (which may also be referred to as export namespaces identifiers) 1, 2, 3, and/or 4, respectively. The mapping table 956-2 in export subsystem 954-2 may indicate that the underlying namespaces NS2, NS 5, NS 6, and/or NS 7 may map to local (export) namespaces identifiers 1, 2, 3, and/or 4, respectively.

In some embodiments, and depending on implementation details, a namespace identifier mapping scheme in accordance with example embodiments of the present disclosure may implement and/or provide any number of the following features. From the perspective of the virtual machine, one or more (e.g., each) sub-controller 916B may be implemented as a derived NVM subsystem with the corresponding sub-controller 916B. Depending on implementation details, sub-controller 916B may be implemented to export NVM subsystem 1) without setting an identifier by host 902: 1 mapping.

By parent controller 916A, host 902 may be capable of creating a namespace (i.e., an underlying namespace) and/or mapping one or more underlying namespaces to one or more export namespaces in export NVM subsystem 954. In some embodiments, the controller may substantially implement the virtual NVM subsystem, e.g., the controller specifies one or more identifiers, wherein one or more export namespaces may be exceptional. In some embodiments, parent controller 916A may implement: (1) Reporting the exported NVM subsystem of the one or more sub-controllers (e.g., using the controller identifier); (2) For example, for new operations, manage export NVM subsystem commands (e.g., host-to-controller data transfer) to initiate controller migration, suspend migrating controllers, resume migrated controllers, and/or the like; and/or (3) manage export namespace commands, for example, for new operations with controller identifiers, and/or to add and/or delete host specified export NSIDs.

Fig. 10 illustrates an embodiment of a migration scheme according to an example embodiment of the present disclosure. The embodiment shown in fig. 10 may include one or more elements that may be similar to elements in one or more other embodiments shown herein, where similar elements may be referred to by and/or include the same numbers, letters, and/or the like.

The embodiment shown in FIG. 10 may include a source host 1002-S and a source device 1004-S, which may be referred to individually and/or collectively as a source system and/or source 1000-S, and which may communicate using a communication architecture and/or communication framework such as that shown in FIG. 1.

Source devices 1004-S may include one or more resources referred to as namespaces 1012-S (identified as namespaces 1S) and/or source subcontrollers 1016B-S that may be assigned to source virtual machines 1006-S running on source hosts 1002-S. The namespaces 1-S, which may be configured as private namespaces, may be attached to the source child controllers 1016B-S. Depending on implementation details, the source virtual machine 1006-S, the source subcontroller 1016B-S, and/or the namespaces 1-S may be configured to operate as logically separate (e.g., isolated) systems, such as using local namespace identifiers to access the namespaces 1-S. Thus, depending on implementation details, the source virtual machine 1006-S, the source subcontroller 1016B-S, and/or the namespaces 1-S may not be aware of and/or be unable to interact with any other virtual machine, controller, namespace, and/or the like.

Source host 1002S may also include a source virtual machine manager 1008-S that may manage one or more virtual machines, such as source virtual machines 1006-S. In some embodiments, the source virtual machine manager 1008-S may control, at least in part, migration of the source virtual machine 1006-S, the source subcontroller 1016B-S, and/or the namespaces 1-S from the source system 1000-S to the target system 1000-T.

The embodiment shown in FIG. 10 may also include target hosts 1002-T and target devices 1004-T, which may be referred to individually and/or collectively as target systems and/or targets 1000-T. Target host 1002T and/or target device 1004T may be provisioned with one or more resources to accommodate migration of virtual machine 1006-S to target system 1000-T. For example, target host 1002T may include one or more computing resources, memory resources, and/or the like, which may be configured to run target virtual machine 1006-T to which source virtual machine 1006-S may migrate (e.g., copy). As another example, target device 1004-T may include one or more resources (e.g., storage resources, computing resources, memory resources, network resources, and/or the like) referred to as namespaces 1012-T (identified as namespaces 1-T), and user data of virtual machine 1006-S may be migrated to namespaces 1012-T. As yet another example, the target device 1004-T may include one or more target sub-controllers 1016B-T to which the controller state of the source sub-controller 1016B-S may be migrated.

Target host 1002T may also include a target virtual machine manager 1008-T, which may manage one or more virtual machines, such as target virtual machines 1006-T. In some embodiments, the target virtual machine manager 1008-T may control, at least in part, migration of the source virtual machine 1006-S, the source subcontroller 1016B-S, and/or the namespaces 1-S from the source system 1000-S to the target system 1000-T.

Source host 1002-S may communicate with source device 1004-S and target host 1002-T may communicate with target device 1000-T using one or more communication structures, frameworks, and/or the like, as described above, for example, with respect to fig. 1, 2, 3, 4, and/or 9. For example, hosts 1002-S and 1002-T may communicate with devices 1004-S and 1004-T, respectively, using PCIe interconnections, where parent controllers 1016A-S and 1016A-T may be implemented with physical functions, and child controllers 1016B-S and 1016B-T may be implemented with virtual functions associated with corresponding physical functions, respectively.

Source host 1002-S may communicate with target host 1002-T using communication path 1007, where communication path 1007 may be implemented with one or more communication structures, frameworks, and/or the like, including interconnects, interfaces, protocols, networks of networks (e.g., the internet), and/or the like, as described above. For example, in some embodiments where the source system 1000-S and the target system 1000-T may be located at the same data center or at different data centers that are relatively close together, the communication path 1007 may be implemented using network technologies such as Ethernet, fibre channel, infiniband, and/or the like. As another example, in some embodiments where the source system 1000-S and the target system 1000-T may be located in relatively remote data centers (e.g., different cities, states, continents, and/or the like), the communication path 1007 may be implemented, at least in part, using the public internet, private network, and/or the like.

In some embodiments, to facilitate migration of source virtual machine 1006-S to target virtual machine 1006-T, source device 1004-S may include source parent controller 1016A-S and/or target device 1004-T may include target parent controller 1016A/T. The source parent controller 1016A/S may be assigned to the source virtual machine manager 1008S and/or the target virtual machine manager 1016A-T may be assigned to the target virtual machine manager 1008-T. Depending on implementation details, namespaces 1-S may be attached to source parent controllers 1016A-S and/or may be otherwise configured to enable source parent controllers 1016A-S to access (e.g., read) namespaces 1-S. Depending on implementation details, namespaces 1-T may be attached to target parent controllers 1016A-T and/or may be otherwise configured to enable target parent controllers 1016A-T to access (e.g., write to) namespaces 1-T.

The first example embodiment of the migration operation of the scheme shown in fig. 10 may proceed as follows. The source virtual machine 1006-S may initially run on the source host 1002-S using the source subcontroller 1016B-S to access the namespaces 1-S. The source host 1002-S may issue a command to suspend the source virtual machine 1006-S. While the source virtual machine 1006-S is suspended, the state of the source virtual machine 1006-S may be transferred to the target virtual machine 1006-T, the target virtual machine 1006-T including, for example, program memory, data memory, one or more management queues 1059, one or more IO queues 1057, and/or the like. Further, while the source virtual machine 1006-S is suspended, the source virtual machine manager 1008-S may read user data 1058 from the namespace 1-S and/or controller state information 1070 from the source child controllers 1016B-S using the source parent controllers 1016A-S, as indicated by arrow 1061. In some embodiments, the source parent controller 1016A-S may read the controller state information 1070 from the source child controllers 1016B-S, as indicated by arrow 1071. The source virtual machine manager 1008-S may communicate user data 1058 and/or controller state information 1070 to the target virtual machine manager 1008-T, as indicated by arrows 1065 and/or 1067, respectively, using, for example, communication path 1007. The target virtual machine manager 1008-T may communicate user data 1058 and/or controller state information 1070 to namespaces 1-T and/or target child controllers 1016B-T, respectively, as indicated by arrow 1063. In some embodiments, the target parent controller 1016A-T may write the controller state information 1070 to the target child controller 1016B-T, as indicated by arrow 1073. The target virtual machine 1006-T may restart (e.g., after some or all of the data has been transferred from the source system 1000-S to the target system 1000-T) and continue to operate using the resources at the target system 1000-T.

The second example embodiment of the migration operation of the scheme shown in fig. 10 (which may be referred to as live migration) may proceed as follows. While the source virtual machine 1006-S is running, the source virtual machine manager 1008-S may begin reading user data of the source virtual machine 1006-S from the memory and/or namespace 1-S and transferring it to the memory and/or namespace 1-T at the target system 1000-T using the target virtual machine manager 1008-T. However, because the source virtual machine 1006-S may still be running, it may change the values in its memory space and/or namespaces 1-S on the source host 1002-S. Thus, source host 1002-S may maintain one or more migration queues for memory and/or namespace data that has become dirty during the migration process. The source virtual machine manager 1008-S may migrate memory and/or namespace data from the one or more migration queues to the target system 1000-T. Virtual machine manager 1008-S may choose to pause source virtual machine 1006-S and transfer any remaining virtual machine memory and/or controller state data and/or namespace user data and/or any data remaining in one or more migration queues to the point of target system 1000-T. The target virtual machine 1006-T may restart (e.g., after some or all of the data has been transferred from the source system 1000-S to the target system 1000-T) and continue to operate using the resources at the target system 1000-T.

Fig. 11 illustrates a first embodiment of a data protection scheme for data transfer operations according to an example embodiment of the present disclosure. The embodiment shown in fig. 11 may include one or more elements that may be similar to elements in one or more other embodiments shown herein, where similar elements may be referred to by and/or include the same reference numerals, letters, and/or the like.

The embodiment shown in fig. 11 may include a host 1102 and a device 1104, which host 1102 and device 1104 may communicate using a communication architecture and/or communication framework such as that shown in fig. 1. Host 1102 may include virtual machine 1106 and/or virtual machine manager 1108, both of which may operate using computing resources, memory resources, and/or the like at host 1102. Device 1104 may include a sub-controller 1116B that may be assigned to virtual machine 1106 and device functional circuitry 1110 that may be attached to sub-controller 1116B.

Virtual machine 1106 can send data 1158 to sub-controller 1116B, which sub-controller 1116B can use protection logic 1160 to apply a protection scheme (e.g., encoding, encrypting, and/or the like) to data 1158 to generate data 1162 (which can be referred to as data having a protection scheme) that can be protected with the protection scheme. The sub-controller 1116B may send data 1162 with the protection scheme to the device function circuitry 1110 (or portions thereof) based on one or more write commands received from the virtual machine 1106, e.g., stored as write data in a storage resource, for processing by a computing resource, for transmission by a communication resource, and/or the like. In some embodiments, the data 1158 received by the sub-controller 1116B may already have one or more types of protection. For example, in addition to the protection scheme that may be applied by the sub-controller 1116B, the data 1158 may also be protected by one or more protection schemes (e.g., encoding, encryption, checksum for error detection, and/or the like).

The sub-controller 1116B may receive data 1162 having a protection scheme from the device functional circuitry 1110 based on one or more read commands received from the virtual machine 1106, e.g., as read data retrieved from a storage resource, as a result of processing by a computing resource, as data received from a communication resource, and/or the like. The sub-controller 1116B may use the protection logic 1160 to modify (e.g., remove, replace, alter, and/or the like) the protection scheme applied to the data 1162 (e.g., decode, decrypt, and/or the like the data 1162) to generate data 1158 that the sub-controller 1116B may send to the virtual machine 1106.

In some embodiments, the sub-controller 1116B may include an error correction function, such as an Error Correction Code (ECC) circuit, that may correct errors in the data exchanged between the sub-controller 1116B and the device function circuit 1110.

Depending on implementation details, the sub-controller 1116B and/or the device functional circuitry 1110 may be configured to appear as separate logic devices (e.g., logic storage devices). For example, the sub-controller 1116B and/or the device function circuitry 1110 may be configured as an NVM subsystem. Thus, virtual machine 1106 can be configured to run one or more operating systems, applications, services, processes, and/or the like, and send user data to device functional circuitry 1110 (or portions thereof), at least from the perspective of virtual machine 1106, device functional circuitry 1110 can appear to be a separate logical device that can be isolated from one or more other resources of device 1104. Thus, depending on implementation details, virtual machine 1106 may not be aware of one or more other controllers, device functional circuits (or portions thereof), and/or the like at device 1104.

Device 1104 may also include a parent controller 1116A, which parent controller 1116A may be assigned to virtual machine manager 1108 and may be configured to provide virtual machine manager 1108 with access to device function circuitry 1110. The parent controller 1116A may read data 1164 that may be protected with a protection scheme from the device function circuitry 1110, e.g., based on one or more read commands received from the virtual machine manager 1108. The parent controller 1116A may include protection logic 1166, and the protection logic 1166 may modify (e.g., remove, replace, alter, and/or the like) the protection scheme applied to the data 1164 (e.g., by decoding, decrypting, and/or the like the data 1164) to generate data 1168 that the parent controller 1116A may send to the virtual machine manager 1108. The parent controller 1116A may send data 1168 to the virtual machine manager 1108, for example, based on one or more read commands received from the virtual machine manager 1108.

In some embodiments, for example, if device function circuitry 1110 is implemented at least in part with a storage medium, data 1162 may be generated by child controller 1116B, and thus, data 1164 read by parent controller 1116A may be the same data 1162 generated by child controller 1116B and stored in device function circuitry 1110. In some other embodiments, the data 1164 may be generated by the device functional circuitry 1110 or an external apparatus, e.g., if the device functional circuitry 1110 is implemented at least in part with computing resources, communication resources, and/or the like, and thus, the data 1164 may include the results of the computation (e.g., based on the data 1162), data received from the external apparatus, and/or the like.

In some embodiments, parent controller 1116A may receive data 1168 from virtual machine manager 1108, e.g., based on one or more write commands received from virtual machine manager 1108. The parent controller 1116A may use protection logic 1166 to generate data 1164 from data 1168 that may be protected with a protection scheme. The parent controller 1116A may send the protected data 1164 to the device function circuitry 1110 (or portions thereof), e.g., based on one or more write commands received from the virtual machine manager 1108.

In some embodiments, parent controller 1116A may include error correction functionality, such as Error Correction Code (ECC) circuitry, which may correct errors in data exchanged between parent controller 1116A and device function circuitry 1110.

In the embodiment shown in fig. 11, host 1102 and device 1104 may communicate using a communication structure, framework, and/or the like, as described with respect to the embodiment shown in fig. 1. For example, in some embodiments, the host 1102 and the device 1104 may communicate using a PCIe fabric, and one or more of the child controllers 1116B and/or the parent controllers 1116A may be implemented at least in part with PCIe functionality (e.g., the parent controller 1116A as a physical function, the child controllers 1116B as virtual functions associated with the physical function). As another example, host 1102 and device 1104 may communicate using a network architecture, and one or more of child controllers 1116B and/or parent controllers 1116A may be implemented at least in part with network endpoints.

Although not limited to any particular application, the embodiment shown in FIG. 11 may be used as part of a migration scheme, for example, to implement one or more of the source system 1000-S and/or the target system 1000-T shown in FIG. 10. For example, if the embodiment shown in FIG. 11 is used to implement the source system 1000-S shown in FIG. 10, the parent controller 1116A and the child controller 1116B may be used to implement the source parent controller 1016A-S and the source child controller 1016B-S, respectively, the device function circuitry 1110 may be used to implement the namespaces 1-S, and/or the virtual machine manager 1108 may be used to implement the virtual machine manager 1008-S. Accordingly, the parent controller 1116A may read protected migration data (e.g., user data) 1164 from the device function circuitry 1110, generate data 1168 as migration data using the protection logic 1166 (e.g., by modifying the protection scheme applied by the child controller 1116B), and send the migration data 1168 to the virtual machine manager 1108 as part of the migration operation to migrate the virtual machine 1106, the child controller 1116B, and/or the device function circuitry 1110 to different locations.

Similarly, if the embodiment shown in FIG. 11 is used to implement the target system 1000-T shown in FIG. 10, the parent controller 1116A and the child controller 1116B may be used to implement the target parent controller 1016A-T and the target child controller 1016B-T, respectively, the device function circuitry 1110 may be used to implement the namespaces 1-T, and/or the virtual machine manager 1108 may be used to implement the virtual machine manager 1008-T. Accordingly, the parent controller 1116A may receive migration data (e.g., user data) 1168 from the virtual machine manager 1108, generate protected data 1164 using protection logic 1166 to apply a protection scheme (e.g., encoding, encryption, and/or the like) to the data 1168, and write the protected data 1164 to the device function circuitry 1110 as part of the migration operation to migrate virtual machines, child controllers, and/or device function circuitry (or data stored therein) from different locations to the virtual machines 1106, child controllers 1116B, and/or device function circuitry 1110 shown in fig. 11.

However, sending data 1168 (which may be, for example, plaintext data) from device 1104 may create one or more security risks. For example, data 1168 may be intercepted and/or used for unauthorized purposes at any point in the data migration path shown in FIG. 10, including, for example, anywhere in the communication structure between source device 1004-S and source host 1002-S, anywhere in the communication path 1007 between source host 1002-S and target host 1002-T (including source virtual machine manager 1008-S), anywhere in the communication structure between target host 1002-T (including target virtual machine manager 1008-T), and/or anywhere in the communication structure between target host 1002-T and target device 1004-T (for example).

Fig. 12 illustrates a second embodiment of a data protection scheme for data transfer operations according to an example embodiment of the present disclosure. The embodiment shown in fig. 12 may include one or more elements that may be similar to the elements shown in fig. 11, where similar elements may be referred to by and/or include the same reference numerals, letters, and/or the like. In the embodiment shown in fig. 12, host 1202 and device 1204 may communicate using a communication structure, framework, and/or the like, as described with respect to the embodiment shown in fig. 1.

In some aspects, the embodiment shown in fig. 12 may operate in a manner similar to the embodiment shown in fig. 11. However, in the embodiment shown in fig. 12, the parent controller 1216A may bypass or omit operations that modify (e.g., remove, replace, alter, and/or the like) the protection scheme applied to the data 1264, e.g., by sending protected data 1264 with the protection scheme applied by the protection logic 1260 at the child controller 1216B to the virtual machine manager 1208 using the transfer path 1276 (e.g., in the protection logic 1266). The parent controller 1216A may send the protected data 1264 to the virtual machine manager 1208, e.g., based on a read command received from the virtual machine manager 1208. Depending on implementation details, this may reduce or eliminate one or more security risks associated with transmitting data (e.g., plaintext data) from the device 1204.

For example, if device 1204 is used to implement source device 1004-S and/or target device 1004-T shown in FIG. 10, protected data 1264 may be protected by some or all of the migration paths between source device 1004-S and target device 1004-T. Furthermore, depending on implementation details, the data 1264 sent by the parent controller 1216A from the device 1204 may be protected using processing (e.g., one or more computations) performed by the protection logic 1260 at the child controller 1216B, and thus, sending data 1264 with a protection scheme may involve little or no additional processing (e.g., computation) by the parent controller 1216A and/or the protection logic 1266.

Although protection logic 1260 and 1266 may be shown as being implemented as part of child controller 1216B and parent controller 1216A, respectively, in some embodiments, any of protection logic 1260 and/or 1266 shown in fig. 12 and/or any other embodiment disclosed herein may be implemented separately from one or more controllers.

Fig. 13 illustrates a third embodiment of a data protection scheme for data transfer operations according to an example embodiment of the present disclosure. The embodiment shown in fig. 13 may include one or more elements that may be similar to the elements shown in fig. 11 and/or 12, where similar elements may be referred to by and/or include the same numbers, letters, and/or the like. In the embodiment shown in fig. 13, the host 1302 and the device 1304 can communicate using a communication structure, framework, and/or the like, as described with respect to the embodiment shown in fig. 1.

In some aspects, the embodiment shown in fig. 13 may operate in a manner similar to the embodiment shown in fig. 12. However, in the embodiment shown in fig. 13, protection logic 1360 at child controller 1316B may be configured to apply a first protection scheme (e.g., encoding, encrypting, and/or the like) to data 1358 to generate data 1362 having the first protection scheme, while protection logic 1366 at parent controller 1316A may be configured to apply a second protection scheme (e.g., encoding, encrypting, and/or the like) to generate data 1380 protected with the second protection scheme based on data 1364. For example, in some embodiments, protection logic 1366 may decrypt data 1364 using a first encryption scheme applied by protection logic 1360 at sub-controller 1316B to generate plaintext data and apply a second encryption scheme to the plaintext data to generate data 1380 that is protected with the second encryption scheme.

In some embodiments, and depending on implementation details, the embodiment shown in fig. 13 may enable a first protection scheme to be used internally for data within device 1304 and a second protection scheme to be used for data sent from device 1304 and/or received at device 1304 using parent controller 1316A. For example, in some embodiments, a first encryption scheme having a first number of bits (e.g., relatively few bits) may be used internally for data within the device 1304 (which may be implemented as a relatively secure environment depending on implementation details), and a second encryption scheme having a second number of bits (e.g., relatively more bits) may be used for data sent to and/or received from an external environment.

Although not limited to any particular application, the embodiments shown in FIG. 12 and/or FIG. 13 may be used as part of a migration scheme, for example, to implement one or more of the source system 1000-S and/or the target system 1000-T shown in FIG. 10.

Fig. 14 illustrates a fourth embodiment of a data protection scheme for data transfer operations according to an example embodiment of the present disclosure. The embodiment shown in fig. 14 may include one or more elements that may be similar to the elements shown in fig. 11, 12, and/or 13, where similar elements may be referred to by and/or include the same numbers, letters, and/or the like. In the embodiment shown in FIG. 14, the host 1402 and the device 1404 may communicate using a communication structure, framework, and/or the like, as described with respect to the embodiment shown in FIG. 1.

In some aspects, the embodiment shown in fig. 14 may operate in a manner similar to the embodiments shown in fig. 11, 12, and/or 13. However, in the embodiment shown in fig. 14, the parent controller 1416A may be configured to receive controller state information 1470 (which may also be referred to as controller metadata) from the child controller 1416B, e.g., in a form that may be at least partially plaintext (e.g., uncoded, unencrypted, and/or the like). The parent controller 1416A may include protection logic 1472, and the protection logic 1472 may generate controller state information 1474 (which may be referred to as protected controller state information 1474) that may be protected using a protection scheme (e.g., encoding, encryption, and/or the like). The parent controller 1416A may send protected controller state information 1474 to the virtual machine manager 1408, e.g., based on commands received from the virtual machine manager 1408 (e.g., read controller state commands).

Examples of controller state information 1470 may include any number of the following: (1) One or more commit queues and/or completion queue pointer states; (2) The contents of one or more commit queues and/or completion queues; (3) One or more settings for underlying transport physical layers, protocols, and/or the like, such as one or more PCIe settings and/or identification information of sub-functions (e.g., virtual functions or physical functions that may be configured as sub-functions, such as PF1, PF2, and/or the like); (4) One or more protocol settings, such as NVMe settings and/or identification information of the sub-controller; and/or the like.

In some embodiments, parent controller 1416A may receive protected (e.g., encoded, encrypted, and/or the like) controller state information 1474 from virtual machine manager 1408, e.g., based on commands (e.g., write controller state commands) received from virtual machine manager 1408. The parent controller 1416A may use protection logic 1472 to modify (e.g., remove, replace, alter, and/or the like) the protection scheme (e.g., decode, decrypt, and/or the like the data 1474) applied to the protected controller state information 1474 to generate controller state information 1470 that the parent controller 1416A may send to the child controller 1416B. In some embodiments, the parent controller 1416A may write controller state information 1470 to the child controller 1416B, e.g., based on commands received from the virtual machine manager 1408 (e.g., write controller state commands). In some embodiments, writing controller state information 1470 to sub-controller 1416B may configure sub-controller 1416B, for example, to place sub-controller 1416B in a state that may be similar or identical to the state of sub-controller 1416B from another location as part of a migration operation.

Although not limited to any particular application, the embodiment shown in FIG. 14 may be used as part of a migration scheme, for example, to implement one or more of the source system 1000-S and/or the target system 1000-T shown in FIG. 10. For example, if the embodiment shown in FIG. 14 is used to implement the source system 1000-S shown in FIG. 10, the parent controller 1416A and child controller 1416B may be used to implement the source parent controller 1016A-S and source child controller 1016B-S, respectively, the device function circuitry 1410 may be used to implement the namespaces 1-S, and/or the virtual machine manager 1408 may be used to implement the virtual machine manager 1008-S. Accordingly, the parent controller 1416A may read the state information 1470 from the child controller 1416B, generate protected controller state information 1474 from the state information 1470 using the protection logic 1472, and send the protected controller state information 1474 to the virtual machine manager 1408, e.g., to enable the state of the child controller 1416B to be migrated to the target child controller 1016B-T as part of migrating the source virtual machine 1006-S to the target virtual machine 1006-T. For example, if device functional circuitry 1410 is implemented with one or more storage resources, computing resources, communication (e.g., network) resources, and/or the like, the embodiment shown in fig. 14 may be used as part of a migration scheme, e.g., in embodiments in which device functional circuitry 1410 may or may not include data that may be migrated.

Similarly, if the embodiment shown in FIG. 14 is used to implement the target system 1000-T shown in FIG. 10, the parent controller 1416A and the child controller 1416B may be used to implement the target parent controller 1016A-T and the target child controller 1016B-T, respectively, the device function circuitry 1410 may be used to implement the namespaces 1-T, and/or the virtual machine manager 1408 may be used to implement the virtual machine manager 1008-T. Accordingly, the parent controller 1416A may receive the protected controller state information 1474 from the virtual machine manager 1408, generate the controller state information 1470 using the protection logic 1472, and write the controller state information 1470 to the child controller 1416B, e.g., to configure the target child controller 1016B-T to operate in the same manner as the source child controller 1016B-S after the source virtual machine 1006-S migrates to the target virtual machine 1006-T and reboots.

Fig. 15 illustrates a fifth embodiment of a data protection scheme for data transfer operations according to an example embodiment of the present disclosure. The embodiment shown in fig. 15 may include one or more elements that may be similar to the elements shown in fig. 2, 3, 4, 11, 12, 13, and/or 14, where similar elements may be indicated by and/or include the same numbers, letters, and/or the like. In the embodiment shown in fig. 15, the host 1502 and the device 1504 may communicate using a communication architecture, framework, and/or the like, as described with respect to the embodiment shown in fig. 1. The embodiment shown in fig. 15 may also include one or more resources (e.g., as part of device functionality circuitry) that may be configured as one or more namespaces 1512.

In some aspects, the embodiment shown in fig. 15 may operate in a manner similar to the embodiments shown in fig. 12, 13, and/or 14. For example, in the embodiment shown in fig. 15, the sub-controller 1516B may include protection logic 1560, and the protection logic 1560 may apply a protection scheme to data (data NS 1) 1558 associated with namespace 1 received from virtual machine 1506 to generate protected data (protected data NS 1) 1562. As another example, parent controller 1516A may include protection logic 1572 to generate protected controller state information 1574 from controller state information 1570. As another example, parent controller 1516A may include protection logic 1566, where protection logic 1566 may generate protected data (protected data NS 1) 1597 based on protected first data (protected data NS 1) 1564 read from namespace 1. Protection logic 1566 may generate protected data 1597, for example, by passing protected first data 1564, by applying a second protection scheme to protected data 1564 (e.g., by decrypting data 1564 using a first encryption algorithm and re-encrypting it using a second encryption algorithm), and/or the like.

The embodiment shown in FIG. 15 may use one or more global namespace identifiers 1514A and/or one or more local namespace identifiers 1514B to identify one or more of namespaces 1512. In some embodiments, as described above with respect to fig. 2, the child controller 1516B and/or the parent controller 1516A may convert the Local namespace identifiers local_ns_1 and/or local_ns_5 into the internal namespace identifiers 1519-1 and/or 1519_5, respectively. If the internal namespace identifier 1519_1 is implemented with a Global namespace identifier, the parent controller 1516A can use the Global namespace identifier Global_NS_1 as the internal namespace identifier 1519-1. Alternatively or additionally, parent controller 1516A may convert Global namespace identifier Global_NS_1 into another format for internal namespace identifier 1519-1.

Thus, the embodiment shown in fig. 15 may combine one or more features related to a namespace identification scheme according to an example embodiment of the present disclosure with one or more features related to data protection according to an example embodiment of the present disclosure, which may produce synergistic results depending on implementation details. For example, in the embodiment shown in FIG. 15, for example, during normal operation in which parent controller 1516A may access its own data in namespace 5, when namespace 5 is accessed using local namespace identifier 1514B, parent controller 1516A may generate data (data NS 5) 1572 from protected data (protected data NS 5) 1569 using protection logic 1555 to access namespace 5. However, when accessing data using Global namespace identifier 1514A (e.g., when migrating user data from namespace 1 using global_ns_1), for example, protection logic 1566 in parent controller 1516A may pass protected data 1564 from namespace 1 to virtual machine manager 1508 (e.g., as protected data 1597) when migrating user data from namespace 1 as part of a migration operation.

Additionally or alternatively, when the parent controller 1516A accesses a namespace that is not shared with the parent controller 1516A, protection logic 1566 in the parent controller 1516A may communicate the protected data 1564 to the virtual machine manager 1508 (e.g., as protected data 1597).

Although protection logic 1555, 1566, and/or 1572 may be illustrated as separate components, in some embodiments, one or more portions of protection logic 1555, 1566, and/or 1572 may be implemented at least in part in a common component (e.g., hardware).

For purposes of illustration, some example embodiments may be described in the context of one or more device functional circuits that may be implemented, at least in part, with one or more storage resources, and/or in the context of one or more protection schemes that may be implemented with encryption, salt, and/or the like, and/or in the context of data migration operations (e.g., in fig. 16-25). However, embodiments having similar features may also be implemented with device functional circuitry, which may be implemented with one or more computing resources, communication resources, memory resources, or a combination thereof, including in combination with memory resources, and/or in combination with one or more protection schemes that may be implemented with one or more other protection techniques, and/or in other contexts.

Fig. 16 illustrates a sixth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure. The embodiment shown in fig. 16 may be used, for example, to implement the embodiment shown in fig. 12. The embodiment shown in fig. 16 may include one or more elements that may be similar to the elements shown in fig. 10-25, where similar elements may be referred to by and/or include the same numbers, letters, and/or the like. As described with respect to the embodiment shown in fig. 1, the embodiment shown in fig. 16 may include one or more hosts 1602 and/or one or more storage devices 1604 that may communicate using a communication fabric, framework, and/or the like.

Referring to fig. 16, storage 1604 may include a sub-controller 1616B, and sub-controller 1616B may receive data 1658 (e.g., plaintext data and/or data that may be protected by additional protection schemes that may be applied by virtual machine 1606) from virtual machine 1606 for user data write operations. The sub-controller 1616B may include protection logic 1660, and the protection logic 1660 may encrypt the data 1658 using an encryption scheme at operation 1682 to generate data 1662 with encryption (e.g., may be protected with an encryption scheme), which may be written to the storage medium 1610. For user data read operations, data 1662 with encryption may be read from storage medium 1610 and decrypted by protection logic 1660 at operation 1683 using an encryption scheme to recover data 1662 into decrypted data 1658, which sub-controller 1616B may send to virtual machine 1606.

Storage 1604 may also include a parent controller 1616A, and the parent controller 1616A may read data with encryption 1662 from storage media 1610. Protection logic 1666 at the parent controller 1616A may pass the encrypted data 1662 (as encrypted data 1664) to the virtual machine manager 1608 (e.g., using pass path 1676). Additionally or alternatively, the parent controller 1616A may receive data 1664 with encryption from the virtual machine manager 1608, which the protection logic 1666 may transfer (as data 1662 with encryption) to the storage medium 1610 (e.g., using transfer path 1676).

Although not limited to any particular application, the embodiment shown in FIG. 16 may be used as part of a migration scheme, for example, to implement the source device 1004-S and/or the target device 1004-T shown in FIG. 10. For example, two storage devices 1604 for implementing source device 1004-S and target device 1004-T may be provided with one or more common encryption algorithms, encryption keys, and/or the like (e.g., by one or more hosts, virtual machine managers, migration servers, and/or the like) to enable one of the storage devices 1604 to decrypt data encrypted by another one of the storage devices 1604.

Fig. 17 illustrates a seventh embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure. The embodiment shown in fig. 17 may be used, for example, to implement the embodiment shown in fig. 12. The embodiment shown in fig. 17 may include one or more elements that may be similar to the elements shown in fig. 10-25, where similar elements may be referred to by and/or include the same numbers, letters, and/or the like.

In some aspects, the embodiment shown in fig. 17 may operate in a manner similar to the embodiment shown in fig. 16. However, in the embodiment shown in fig. 17, protection logic 1760 may include a salt value (which may also be referred to as trim (tweak)) and data 1758 for the write operation. The encryption operation 1782 may encrypt the combined data 1758 and salt value to generate encrypted data and salt value 1762 that the sub-controller 1716B may store in the storage medium 1710. For write operations, the sub-controller 1716B may read the encrypted data and the salt 1762 from the storage medium 1710. Protection logic 1760 may decrypt the combined data and salt value in a decryption operation 1783 to recover original data 1758 and sub-controller 1716B may send original data 1758 to virtual machine 1706.

In some embodiments, protection logic 1766 at parent controller 1716A may read the encrypted data and salt 1762 from storage medium 1710 and pass the encrypted data and salt 1762 (as encrypted data and salt 1764) to virtual machine manager 1708, e.g., using pass-through path 1776. The protection logic 1766 may also pass the encrypted data and salt 1764 received from the virtual machine manager 1708 to the storage medium 1710 (as encrypted data and salt 1762).

In some embodiments, for example, if the storage device 1704 is used to implement a data migration scheme, the salt value that can be used by the source storage device can be used by the target storage device (e.g., shared with the target storage device), e.g., to enable the target storage device to decrypt the encrypted data and the salt value 1762. For example, salt values may be shared across one or more devices 1704 using I/O commands, dedicated messages, management commands, salt value data structures (e.g., tables) that may be exchanged between one or more components, storage devices in a generally accessible location, and/or the like.

The salt value used to create the combined encrypted data and salt value 1762 may be selected, created, provided, and/or the like by the storage device 1704, host 1702, and/or the like. Examples of information that may be used as a salt value may include random or pseudo-random numbers, logical Block Addresses (LBAs) of data 1758, physical storage media (e.g., NAND memory) addresses of data 1758, namespaces and/or the like of data 1758, or a combination thereof. In some example embodiments, the salt value may be implemented with a concatenation, multiplexing, multiplication, addition, and/or the like of the namespace IDs of LBAs and data 1758. In some embodiments, the salt value may be implemented with an offset value, a seed value, and/or the like, which may be determined by a host, a device, or a combination thereof. In some embodiments, the salt value may be implemented with an initial value and incremented and/or decremented, for example, for one or more access commands (e.g., for each read and/or write command). In some embodiments, the salt value may be implemented with rules selected by the host and/or device (e.g., LBA, LBA+ (offset seed provided by the host and/or device), a higher and/or lower namespace of salt values and/or concatenation of LBAs, with different salt values provided by one or more (e.g., each read and/or write command), and/or the like).

Fig. 18 illustrates an eighth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure. The embodiment shown in fig. 18 may be used, for example, to implement the embodiment shown in fig. 13. The embodiment shown in fig. 18 may include one or more elements that may be similar to the elements shown in fig. 10-25, wherein similar elements may be referred to by and/or include the same numbers, letters, and/or the like.

In some aspects, the embodiment shown in fig. 18 may operate in a similar manner as the embodiment shown in fig. 17. In particular, for write operations, protection logic 1860 at sub-controller 1816B may encrypt data 1858 received from virtual machine 1806 with a salt value at operation 1882 to generate encrypted data and salt value 1862 that sub-controller 1816B may store in storage medium 1710. For read operations, protection logic 1860 may decrypt the encrypted data and salt 1862 and send data 1858 to virtual machine 1806

However, in the embodiment shown in FIG. 18, for a read operation, protection logic 1866 at parent controller 1816A may remove the salt value and re-encrypt data 1858 to send encrypted data 1864 to virtual machine manager 1864. In particular, protection logic 1866 may decrypt the encrypted data and salt 1862 at operation 1883 (e.g., using the same encryption algorithm(s), key(s), and/or the like used by protection logic 1860 at child controller 1816B for operation 1882), remove the salt at operation 1887, and re-encrypt data 1858 at operation 1882 to generate encrypted data 1864, which parent controller 1816A may send to virtual machine manager 1808. For write operations, protection logic 1866 may receive encrypted data 1864 from virtual machine manager 1808, decrypt encrypted data 1864 at operation 1883 (e.g., using the same encryption algorithm(s), key(s), and/or the like used by protection logic 1860 at sub-controller 1816B for operation 1882), add a salt value at operation 1886, and re-encrypt data 1858 at operation 1882. The parent controller 1816A may store the encrypted data and salt 1862 in the storage medium 1810.

Thus, in the embodiment shown in fig. 18, a first data protection scheme (e.g., encryption using salt values) may be used internal to the storage device 1804, while a second data protection scheme (e.g., encryption) may be used for data exchanged with the storage device (e.g., external).

In some embodiments, and depending on implementation details, the embodiment shown in fig. 18 may enable the storage device 1804 to provide enhanced protection within the device 1804 while still protecting the data 1858 by sending the data 1858 in encrypted form 1864, e.g., as part of a data migration operation. Further, depending on implementation details, the embodiment shown in fig. 18 may reduce or eliminate sharing of one or more salt values across the storage device 1804.

Fig. 19 illustrates a ninth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure. The embodiment shown in fig. 19 may be used, for example, to implement the embodiment shown in fig. 13. The embodiment shown in fig. 19 may include one or more elements that may be similar to the elements shown in fig. 10-25, where similar elements may be referred to by and/or include the same numbers, letters, and/or the like.

In some aspects, the embodiment shown in fig. 19 may operate in a similar manner as the embodiment shown in fig. 18. However, in the embodiment shown in fig. 19, the protection logic 1966 at the parent controller 1916A may change (e.g., swap) the salt value instead of adding and/or removing the salt value. For example, for a write operation, the protection logic 1960 at the sub-controller 1916B may encrypt the data 1958 using a first salt value (salt 1) at operation 1982 to generate encrypted data and the first salt 1962. For a read operation (e.g., as part of a data migration operation), protection logic 1966 at parent controller 1916A may decrypt the encrypted data and first salt 1962 at operation 1983 to recover data 1958 and first salt. The protection logic 1966 may change the first salt value (e.g., swap the first salt value (salt 1) to the second salt value (salt 2) at operation 1989.) the protection logic 1966 may re-encrypt the combined data 1958 and the second salt value to generate encrypted data and the second salt 1964 at operation 1982, which the parent controller 1916A may send to the virtual machine manager 1908.

Any of the operations disclosed herein for changing the salt value may be implemented using any suitable technique. For example, in some embodiments, the protection logic 1966 may convert (e.g., directly convert) the first salt value to a second salt value, e.g., using an inline operation. As another example, in some embodiments, the protection logic 1966 may incrementally change the salt values, for example, by first removing one salt value, then adding (e.g., attaching, cascading, and/or the like) another salt value. In some embodiments, the protection logic 1966 may use an isolated security core to perform a salt change operation (e.g., any of the example embodiments of salt change operations described above) to protect user data from unauthorized access during the salt change operation.

Although not limited to any particular implementation details, in some embodiments, a salt value of 1 may be determined by storage device 1904 and a salt value of 2 may be determined by host 1902. Depending on implementation details, this may enable a relatively strong protection scheme (e.g., encryption scheme) to be used for data internal to storage devices 1904 as well as data exchanged externally, while reducing or eliminating exchange of one or more salt values between storage devices. For example, in some embodiments, a first salt value (salt 1) used internally to storage device 1904 may be selected by protection logic 1960 at sub-controller 1916B based on a physical storage media location ID, an LBA concatenated with a namespace ID, and/or the like, while a second salt value (salt 2) used to externally send and/or receive data may be selected by host 1902 based on an LBA, an LBA plus offset seed provided by host 1902, a concatenation of an LBA and a namespace, a salt provided for one or more (e.g., each) read and/or write commands, and/or the like.

Fig. 20 illustrates a tenth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure. The embodiment shown in fig. 20 may be used, for example, to implement the embodiment shown in fig. 12. The embodiment shown in fig. 20 may include one or more elements that may be similar to the elements shown in fig. 10-25, where similar elements may be referred to by and/or include the same numbers, letters, and/or the like.

In some aspects, the embodiment shown in fig. 20 may operate in a similar manner as the embodiment shown in fig. 16. However, the embodiment shown in fig. 20 may implement a per IO Key (KPIO) scheme in which a host 2002 (e.g., virtual machine 2006, virtual machine manager 2008 and/or the like) may specify encryption keys that may be used for one or more (e.g., each) IO requests (e.g., read commands, write commands, and/or the like) of data 2058. The KPIO scheme may be implemented, for example, using KPIO key storage device 2079, and KPIO key storage device 2079 may receive KPIO key identifier (KPIO key ID) 2090 as input and provide KPIO encryption key 2091 as output. As another example, KPIO encryption key 2091 may be provided by host 2002 (e.g., directly). Alternatively or additionally, virtual machine manager 2008 can establish KPIO key ID 2090 for the VM. In such embodiments, a particular key may be assigned (e.g., always assigned) to a particular virtual machine, sub-controller, namespace, other identifier, and/or the like. Depending on implementation details, this may enable a virtual machine that is not configured for KPIO operations to use a KPIO infrastructure that may be established by virtual machine manager 2008.

For example, for a write operation, the sub-controller 2016B may receive the write data 2058, and the storage device 2004 may receive a corresponding KPIO key ID 2090, which may be used to retrieve the KPIO encryption key 2091 using the KPIO key storage device 2079. The protection logic 2060 in the subcontroller 2016B may encrypt data 2058 using the KPIO encryption key 2091 in operation 2082 to generate encrypted data 2062, and the subcontroller 2016B may store the encrypted data 2062 in the storage medium 2010. For read operations, at operation 2083, the protection logic 2060 may decrypt the data 2058 using the KPIO encryption key 2091 associated with the encrypted data 2062.

In some embodiments, IOs may be referred to as requests, and keys per IO may be referred to as keys per request. In some embodiments, the per IO key may refer to a key that may be used for one or more IOs. For example, virtual machine 2006 or other user may send a first IO to storage device 2004 along with a first KPIO key (or a first KPIO key ID that is used to indicate the first KPIO key), which may be used to protect first data sent with the first IO. The virtual machine 2006 or other user may send the second IO to the storage device 2004 along with a second KPIO key (or a second KPIO key ID to indicate the second KPIO key), which may be used to protect data sent with the second IO.

In some embodiments, protection logic 2066 at parent controller 2016A may pass data with KPIO encryption 2062 (as data with KPIO encryption 2064) to virtual machine manager 2008 (e.g., using pass path 2076). Additionally or alternatively, parent controller 2016A may receive data with encryption 2064 from virtual machine manager 2008, which protection logic 2066 may transfer (as data with encryption 2062) to storage medium 2010 (e.g., using transfer path 2076).

In some embodiments, KPIO storage 2079 may be implemented, for example, with data structures such as tables, lists, databases, key-value stores, and/or the like, and KPIO key ID 2090 may be implemented with pointers, indexes, and/or the like to the data structures. In some embodiments, KPIO storage 2079 may be initialized (e.g., populated with one or more KPIO keys) at startup, e.g., by host 2002, and access subsequent IO requests using one or more KPIO key IDs 2090.

Fig. 21 illustrates an eleventh embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure. The embodiment shown in fig. 21 may be used, for example, to implement the embodiment shown in fig. 12. The embodiment shown in fig. 21 may include one or more elements that may be similar to the elements shown in fig. 10-25, where similar elements may be referred to by and/or include the same numbers, letters, and/or the like.

In some aspects, the embodiment shown in fig. 21 may operate in a manner similar to the embodiment shown in fig. 20. However, in the embodiment shown in fig. 21, for a write operation, protection logic 2160 at sub-controller 2116B may receive KPIO salt value 2192 (e.g., as determined by host 2102 as described above), protection logic 2160 may combine KPIO salt value 2192 with data 2158 at operation 2182 and encrypt using KPIO key 2191 to generate encrypted data and KPIO salt value 2162, where sub-controller 2116B may store the encrypted data and KPIO salt value 2162 in storage medium 2110. For a read operation, at operation 2183, protection logic 2160 may decrypt the encrypted data and KPIO salt value 2162 using KPIO encryption key 2191 associated with the encrypted data 2162, and send data 2158 to virtual machine 2106.

In some embodiments, protection logic 2166 at parent controller 2116A may pass data with KPIO encryption and KPIO salt value 2162 (as data with KPIO encryption and KPIO salt value 2164) to virtual machine manager 2108 (e.g., using pass path 2176). Additionally or alternatively, the parent controller 2116A may receive the data with KPIO encryption and KPIO salt value 2164 from the virtual machine manager 2108, which the protection logic 2166 may transfer (as with the encrypted data and KPIO salt value 2162) to the storage medium 2110 (e.g., using the transfer path 2176).

Although the KPIO salt value 2192 may be shown in fig. 21 as being provided by the host 2102 (e.g., directly), in some embodiments the KPIO salt value 2192 may be provided to the protection logic 2160 using any other technique. For example, one or more KPIO salt values 2192 may be stored in a KPIO salt value storage device, and the host 2102 may provide a KPIO salt value ID to the storage device 2104, where the KPIO salt value ID may be used to retrieve the KPIO salt value 2192 from the KPIO salt value storage device.

Fig. 22 illustrates a twelfth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure. The embodiment shown in fig. 22 may be used, for example, to implement the embodiment shown in fig. 13. The embodiment shown in fig. 22 may include one or more elements that may be similar to the elements shown in fig. 10-25, wherein similar elements may be referred to by and/or include the same numbers, letters, and/or the like.

In some aspects, the embodiment shown in fig. 22 may operate in a manner similar to the embodiment shown in fig. 19 and/or 21, and/or combine one or more features of the embodiment shown in fig. 19 and/or 21. However, the embodiment shown in fig. 22 may use a first salt value for KPIO encryption of data that may be used (e.g., stored) within storage device 2204, and a second salt value for KPIO encryption of data that may be communicated externally (e.g., as part of a data migration operation).

For example, for a write operation, protection logic 2260 at sub-controller 2216B may combine the first salt value (salt value 1) with data 2258 and encrypt the combined data 2258 and first salt value using KPIO encryption key 2291 selected by the host using KPIO key ID 2290 to generate encrypted data and first salt value 2262 that sub-controller 2216B may store in storage medium 2210. For a read operation, the sub-controller 2216B may read the encrypted data and the first salt 2262 from the storage medium 2210. At operation 2283, the protection logic 2260 may decrypt the encrypted data and the first salt 2262 to recover the data 2258 that the sub-controller 2216B may send to the virtual machine 2206.

However, protection logic 2266 at parent controller 2216A may change the first salt value (salt 1) to the second salt value (salt 2). For example, for a read operation (e.g., migrating data 2258 to a target storage device), the parent controller 2216A may read the encrypted data and the first salt 2262 from the storage medium 2210. The protection logic 2266 may decrypt the encrypted data and the first salt 2262 at operation 2283 to recover the data 2258 and the first salt. The protection logic 2266 may exchange the first salt value (salt 1) for the second salt value (salt 2) at operation 2289 and re-encrypt the combined data 2258 and second salt value to generate encrypted data and second salt 2264 at operation 2282, where the parent controller 2216A may send the encrypted data and second salt 2264 to the virtual machine manager 2208. For write operations (e.g., migrating data 2258 from the source storage device), the protection logic 2266 may perform the reverse order, wherein the encrypted data received from the virtual machine manager 2208 and the second salt 2264 may be decrypted at operation 2283. The protection logic 2266 may exchange the second salt value (salt 2) for the first salt value (salt 1) at operation 2288 and re-encrypt the combined data 2258 and first salt value to generate encrypted data and first salt 2262 at operation 2282, where the parent controller 2216A may store the encrypted data and first salt 2262 in the storage medium 2210.

Although not limited to any particular implementation details, in some embodiments, salt 1 may be determined by storage device 2204 and salt 2 may be determined by host 2202. Depending on implementation details, this may enable a relatively strong protection scheme (e.g., encryption scheme) to be used for data internal to storage device 2204 as well as data exchanged externally, while reducing or eliminating exchange of one or more salt values between storage devices.

Fig. 23 illustrates a thirteenth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure. The embodiment shown in fig. 23 may be used, for example, to implement the embodiment shown in fig. 13. The embodiment shown in fig. 23 may include one or more elements that may be similar to the elements shown in fig. 10-25, where similar elements may be referred to by and/or include the same numbers, letters, and/or the like.

In some aspects, the embodiment shown in fig. 23 may operate in a manner similar to the embodiment shown in fig. 16. However, in the embodiment shown in fig. 23, protection logic 2366 at parent controller 2216A may use a second encryption scheme to protect data sent from parent controller 2216A and/or received at parent controller 2216A. For example, in some aspects, the protection logic 2260 at the sub-controller 2316B may operate in a similar manner to the protection logic 1660 at the sub-controller 1616B shown in fig. 16 using a first encryption scheme (e.g., encryption algorithm, setting, and/or the like, which may be referred to as encryption code 1 or encryption 1).

However, for a read operation (e.g., migrating data 2358 to a target device), protection logic 2366 at parent controller 2216A may replace the first encryption scheme with a second encryption scheme (e.g., encryption algorithm, settings, and/or the like, which may be referred to as (encryption code 2 or encryption 2)). Specifically, the parent controller 2216A may read the data 2362 having the first encryption scheme from the storage medium 2310. Protection logic 2366 may decrypt encrypted data 2362 using the first encryption scheme at operation 2383 to recover data 2358. Protection logic 2366 may re-encrypt data 2358 using the second encryption scheme at operation 2394 to generate data 2364 with the second encryption, which may be sent by parent controller 2216A to virtual machine manager 2308. Protection logic 2366 may re-encrypt data 2358 using the first encryption scheme at operation 2382 to generate data 2362 having the first encryption scheme, which may be written by parent controller 2216A to storage medium 2310.

Any of the encryption schemes disclosed herein, including the first and second encryption schemes described in the context of fig. 23, may be implemented with any type of encryption settings, algorithms, modes, and/or the like. Examples may include Advanced Encryption Standards (AES) 128, 256, and/or the like having any pattern (e.g., a pattern that may use exclusive or (XOR), such as XOR Encryption XOR (XEX), XEX trimmable block ciphers (XTS) with ciphertext stealing, galois/counter patterns (GCM), cipher Block Chaining (CBC), and/or the like). Additionally or alternatively, the encryption key (and/or any other potential encryption options, settings, modes, and/or the like) used during the encryption process may vary. For example, a first key implemented with AES 128XTS may be used for internal encryption (e.g., encryption 1), while a second key implemented with AES256XEX may be used for external encryption (e.g., encryption 2).

While not limited to any particular implementation details, in some embodiments the first encryption scheme described in the context of fig. 23 may be implemented with one or more algorithms, settings, keys, and/or the like, which may involve relatively few resources (e.g., processing time, power consumption, memory usage, and/or the like), which may provide an amount of protection that may be acceptable for use within the storage device 2304, which may represent a relatively secure environment. Rather, the second encryption scheme may be implemented with one or more algorithms, settings, keys, and/or the like, which may involve relatively more resources, which may provide an amount of protection that may be acceptable for use with data that may be subject to a relatively unsecure environment external to the storage device 2304.

As yet another example, the first encryption scheme may be implemented with a homomorphic encryption scheme, and the second encryption scheme may be implemented with a Post Quantum Cryptography (PQC) scheme. Depending on implementation details, in such embodiments, using homomorphic encryption for the first encryption scheme within the relatively secure environment of the storage device 2304 may enable one or more operations (e.g., computations) to be performed on data stored within the storage device while it is still encrypted. However, changing homomorphic encryption to a PQC encryption scheme before data is sent outside of storage device 2304 may enable a greater amount of protection to be provided for relatively unsecure environments outside of storage device 2304.

Fig. 24 illustrates a fourteenth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure. The embodiment shown in fig. 24 may be used, for example, to implement the embodiment shown in fig. 13. The embodiment shown in fig. 24 may include one or more elements that may be similar to the elements shown in fig. 10-23 and 25, where similar elements may be referred to by and/or include the same numbers, letters, and/or the like.

In some aspects, the embodiment shown in fig. 24 may operate in a similar manner to the embodiment shown in fig. 18 and/or 23, and/or combine one or more features of the embodiment shown in fig. 18 and/or 23. For example, in the embodiment shown in fig. 24, protection logic 2466 at parent controller 2416A may add or remove salt values in a similar manner as protection logic 1866 in the embodiment shown in fig. 18. However, the protection logic 2466 shown in fig. 24 may use a first encryption scheme (encryption code 1 or encryption 1) for data to be used (e.g., stored) inside the storage 2404 and a second encryption scheme (encryption code 2 or encryption 2) for data to be sent from the parent controller 2416A or received at the parent controller 2416A.

Fig. 25 illustrates a fifteenth embodiment of a data protection scheme for data transfer operations according to an example embodiment of the present disclosure, which shows some example implementation details. The embodiment shown in fig. 25 may be used, for example, to implement the embodiment shown in fig. 13. The embodiment shown in fig. 25 may include one or more elements that may be similar to the elements shown in fig. 10-25, wherein similar elements may be referred to by and/or include the same numbers, letters, and/or the like.

In some aspects, the embodiment shown in fig. 25 may operate in a similar manner to the embodiment shown in fig. 19 and/or 24 and/or combine one or more features of the embodiment shown in fig. 19 and/or 24. For example, protection logic 2566 at parent controller 2516A may use a first encryption scheme (encryption code 1 or encryption 1) for data to be used (e.g., stored) inside storage 2504 and a second encryption scheme (encryption code 2 or encryption 2) for data to be sent from parent controller 2516A or received at parent controller 2516A. However, the protection logic 2566 shown in fig. 25 may exchange the first salt (salt 1) and the second salt (salt 2) in a similar manner to the embodiment shown in fig. 19, rather than adding and/or removing salt as described with respect to the embodiment shown in fig. 24.

Although not limited to any particular implementation details, in some embodiments, a first salt value (salt 1) may be determined by the storage device 2504 and a second salt value (salt 2) may be determined by the host 2502. For example, in some embodiments, host 2502 may specify that an LBA and/or a namespace ID (e.g., an LBA combined with a namespace ID of data 2558, e.g., by concatenating) may be used for the first salt. As another example, in some embodiments, host 2502 may specify that the first salt value may be incremented for one or more (e.g., each) IO requests to read and/or write data 2558.

Fig. 26 illustrates a sixteenth embodiment of a data protection scheme for data transfer operations, showing some example implementation details, according to an example embodiment of the present disclosure. The embodiment shown in fig. 26 may be used, for example, to implement the embodiment shown in fig. 13. The embodiment shown in fig. 26 may include one or more elements that may be similar to the elements shown in fig. 10-25, where similar elements may be referred to by and/or include the same numbers, letters, and/or the like. In some aspects, the embodiment shown in fig. 26 may operate in a similar manner to the embodiment shown in fig. 22 and/or 25 and/or combine one or more features of the embodiment shown in fig. 22 and/or 25.

In the embodiment shown in fig. 26, protection logic 2660 at child controller 2616B and protection logic 2666 at parent controller 2616A may use a first protection scheme (e.g., first KPIO key 2691 and/or first KPIO salt value (salt value 1) 2692) to protect data 2658 inside storage device 2604. The protection logic 2666 at the parent controller 2616A may use a second protection scheme (e.g., a second KPIO key 2698 and/or a second KPIO salt value (salt value 2) 2699) to protect data sent from the parent controller 2616A and/or received at the parent controller 2616A, e.g., as part of a data migration operation.

The embodiment illustrated in fig. 26 is not limited to any particular technique(s) for selecting, providing, and/or the like for the first KPIO key 2691 and the second KPIO key 2698 and/or the first salt value (salt 1) and the second salt value (salt 2).

In some example embodiments, the first KPIO key 2691 and/or the second KPIO key 2698 may be selected by the virtual machine manager 2608 using the first KPIO key identifier 2690 and/or the second KPIO key identifier 2696, respectively. For example, the virtual machine manager 2608 may send the first KPIO key identifier 2690 and/or the second KPIO key identifier 2696 with a command (e.g., a data read or write command), status information of the child controller 2616B and/or the parent controller 2616A, and/or the like. In some embodiments, techniques for selecting, providing, and/or the like, one or more encryption keys may additionally or alternatively include selecting, providing, and/or the like, one or more encryption settings.

In some example embodiments, as shown in fig. 26, the first KPIO salt value 2692 may be provided by the host 2602. Alternatively or additionally, the first KPIO salt value 2692 may be determined by the sub-controller 2616B, e.g., as part of status information, as part of a configuration operation, and/or the like. In some example embodiments, as shown in fig. 26, a second KPIO salt value 2699 may be provided by the host 2602. Alternatively or additionally, the second KPIO salt value 2699 may be determined by the parent controller 2616A, e.g., as part of status information, as part of a configuration operation, and/or the like.

Some example embodiments of the first protection scheme (e.g., used by the child controller 2616B and the parent controller 2616A to protect data inside the storage 2604) may be implemented as follows. In some embodiments, virtual machine 2606 may use different keys for one or more IO requests (e.g., different keys for each request). In some embodiments, virtual machine 2606 may use one or more keys on a namespace basis (e.g., different keys for each namespace, where the same key is used for each IO request for a particular namespace). In some embodiments, virtual machine 2606 may use one or more keys on a controller basis (e.g., the same key is used for all IO requests of its associated sub-controller 2616B). In some embodiments, virtual machine manager 2608 can set one or more keys (e.g., a single key) for one or more (e.g., each) of the virtual machines' associated namespaces. In some embodiments, virtual machine manager 2608 can set one or more keys (e.g., a single key) for one or more (e.g., each) of the associated sub-controllers of the virtual machine.

Some example embodiments of the second protection scheme (e.g., used by the parent controller 2616A to protect data sent to the parent controller 2616A and/or sent from the parent controller 2616A) may be implemented below. In some embodiments, virtual machine manager 2608 may set one or more keys (e.g., a single key) for one or more (e.g., each) IO requests. In some embodiments, virtual machine manager 2608 can set one or more keys on a namespace basis, e.g., one or more keys (e.g., a single key) for one or more (e.g., each) global namespace identifiers. In some embodiments, the virtual machine manager 2608 may set one or more keys (e.g., a single key) for the sub-controller 2616B that may involve the migration operation.

For write operations by the sub-controller 2616B, the protection logic 2660 may attach a first KPIO salt value of 1 2692 (which may be provided, for example, by the host 2602 (e.g., by the virtual machine 2606, virtual machine manager 2608, and/or the like) to the received data 2658, and at operation 2682, encrypt a combination of the data 2658 and the salt value of 1 using the first KPIO key 2691 to generate data 2662 protected with the first protection scheme (e.g., the combined data 2658 and the salt value of 1 encrypted with the first KPIO key 2691), which the sub-controller 2616B may write to the storage medium 2610.

For a read operation by the sub-controller 2616B, the sub-controller 2616B may read the data 2662 protected with the first protection scheme (e.g., the combined data 2658 and the salt 1 encrypted with the first KPIO key 2691) from the storage medium 2610. The protection logic 2660 may decrypt the combined data 2658 and salt 1 using the first KPIO key 2691 at operation 2683 to recover the data 2658 that the sub-controller 2616B may send to the host 2602.

For write operations by the parent controller 2616A, the parent controller 2616A may receive data 2664 protected with a second protection scheme (e.g., combined data 2658 and salt 2 encrypted with a second KPIO key 2698). The second salt (salt 2) 2699 may be provided, for example, by the host 2602 (e.g., by the virtual machine manager 2608). The second KPIO key 2698 may be selected, provided, and/or the like by the host 2602 (e.g., by the virtual machine manager 2608), e.g., using the second KPIO key identifier 2696. The protection logic 2666 may decrypt the data 2664 protected with the second protection scheme using the second KPIO key 2698 at operation 2695 to recover the data 2658 and the salt 2. At operation 2688, the protection logic 2666 may change the second salt value (salt value 2) to the first salt value (salt value 1). At operation 2682, the protection logic 2666 may encrypt the combined data 2658 and salt 1 using the first KPIO key 2691 to generate data 2662 protected with the first protection scheme (e.g., the combined data 2658 and salt 1 encrypted with the first KPIO key 2691), which the parent controller 2616A may write to the storage medium 2610.

For a read operation by the parent controller 2616A, the parent controller 2616A may read the data 2662 protected with the first protection scheme (e.g., the combined data 2658 and the salt 1 encrypted with the first KPIO key 2691) from the storage medium 2610. The protection logic 2666 may decrypt the data 2662 protected with the first protection scheme using the first KPIO key 2691 at operation 2683 to recover the combined data 2658 and salt 1. At operation 2689, the protection logic 2666 may change the first salt value (salt 1) to the second salt value (salt 2). At operation 2694, the protection logic 2666 may encrypt the combined data 2658 and salt 2 using the second KPIO key 2698 to generate data 2664 protected with the second protection scheme, wherein the parent controller 2616A may send the data to the host 2602.

Fig. 27 illustrates an embodiment of a data protection scheme for data transfer operations in which device function circuitry may modify data, according to an example embodiment of the present disclosure. The embodiment shown in fig. 27 may include one or more elements that may be similar to the elements shown in fig. 12 and/or 13, where similar elements may be referred to by and/or include the same numbers, letters, and/or the like.

However, in the embodiment illustrated in FIG. 27, device functional circuitry can be implemented with storage medium 2710 and/or computing storage device 2711, which can modify data written to storage medium 2710 using, for example, one or more computing resources 2713. Accordingly, depending on implementation details, the data read from the storage medium 2710 may be different from the data written to the storage medium 2710. Additionally or alternatively, the computing storage device 2711 may include one or more controllers (e.g., additional or alternative sub-controllers, such as sub-controller 2716B).

For example, protection logic 2760 at sub-controller 2716B may receive sub-write data 2758A from virtual machine 2706 at host 2702. The protection logic 2760 may apply a first protection scheme (e.g., encoding, encrypting, and/or the like) to the sub-write data 2758A to generate sub-write data 2762A with the first protection scheme that the sub-controller 2716B may write using the data path 2715 to the address in the storage medium 2710. However, the computing storage 2711 may perform one or more operations (e.g., computations) on the protected data stored at addresses in the storage medium 2710. Thus, when the sub controller 2716B reads sub read data 2762B having the first protection scheme from the same address in the storage medium 2710, it may be different from sub write data 2762A having the first protection scheme written to the address. The protection logic 2760 may modify (e.g., remove, replace, alter, and/or the like) a first protection scheme (e.g., decode, decrypt, and/or the like) applied to the sub-read data 2762B to generate sub-read data 2758B, which sub-read data 2758B may differ from the sub-write data 2758A depending on implementation details. Sub-controller 2716B may send sub-read data 2758B to virtual machine 2706.

In some embodiments, protection logic 2766 at parent controller 2716A may exchange, convert, replace, convert, and/or the like between the first protection scheme and the second protection scheme in some ways that may be similar to the embodiment shown in fig. 13. For example, parent controller 2716A may receive parent write data 2780A with a second protection scheme from virtual machine manager 2708 at host 2702, remove the second protection scheme and apply the first protection scheme to the parent write data to generate parent write data 2764A with the first protection scheme, wherein parent controller 2716A may write parent write data 2764A with the first protection scheme to a storage address in storage medium 2710.

However, in the embodiment shown in FIG. 27, computing storage device 2711 may perform one or more operations (e.g., computations) on the protected data stored at the address in storage medium 2710. Thus, when parent controller 2716A reads parent read data 2764B with the first protection scheme from an address in storage medium 2710, it may be different from parent write data 2764A with the first protection scheme and/or child write data 2762A with the first protection scheme that may have been written to the address.

Protection logic 2766 may remove the first protection scheme and apply the second protection scheme to generate parent read data 2780B with the second protection scheme, which parent controller 2716A may send to virtual machine manager 2708 at host 2702.

In some embodiments, the first protection scheme and the second protection scheme may be the same. For example, in such an embodiment, protection logic 2766 may use one or more transfer paths (which may be similar to transfer path 1276 shown in, for example, fig. 12) to transfer parent read data 2764B with a first protection scheme to virtual machine manager 2708 (e.g., directly to virtual machine manager 2708) as parent read data 2780B with a second protection scheme. Similarly, in such embodiments, protection logic 2766 may use the transfer path to transfer parent write data 2780A with the second protection scheme from virtual machine manager 2708 to storage medium 2710 (e.g., directly to storage medium 2710) as parent write data 2764A with the first protection scheme.

Although not limited to any particular application, the embodiment shown in FIG. 27 may be used, for example, to implement a computing storage scheme that may enable homomorphic computing (e.g., computing that may be performed on data in an encrypted state). In some example embodiments, the first protection scheme may be implemented with homomorphic encryption, while the second protection scheme may be implemented with another type of encryption that may be more suitable for transferring data across the communication fabric between host 2702 and device 2704. In some embodiments, homomorphic encryption may enable computing resource 2713 to perform one or more operations (e.g., computations) on encrypted data stored in storage medium 2710 without decrypting the data. For example, computing resource 2713 may read protected (e.g., encrypt) data from one or more storage addresses in storage medium 2710, perform one or more operations (e.g., computations) on the protected data, and store modified protected data (e.g., encryption results) at one or more of the same and/or different addresses in storage medium 2710.

In some embodiments, the second protection scheme may be implemented, for example, with a relatively stronger type of protection, such as a Post Quantum Cryptography (PQC) scheme. In some embodiments, the PQC scheme may be implemented with a type of encryption that may be strong enough to withstand attacks by quantum computers. Thus, in some embodiments, the first protection scheme may be implemented with homomorphic encryption within a relatively secure environment within the device 2704, while the second protection scheme may be implemented with PQCs to provide relatively stronger protection against data communicated between the host 2702 and the device 2704 using a relatively less secure communication structure. In some embodiments, the PQC encryption scheme may be implemented with a encryption engine that may be different, separate, and/or the like from one or more forms of protection logic described herein.

One or more of the aspects of the present disclosure described with respect to fig. 27 may be combined with any of the other aspects disclosed herein. For example, in some embodiments, the first protection scheme and/or the second protection scheme used in the embodiment shown in fig. 27 may be implemented with one or more of the encryption schemes, salt schemes, KPIO schemes, and/or the like described above with respect to the embodiments shown in fig. 16-25, or a combination thereof.

FIG. 28 illustrates an embodiment of a method for data protection for controller state migration operations, according to an example embodiment of the present disclosure. For purposes of illustration, the embodiment shown in FIG. 28 may be described in the context of an embodiment in which host 1402 shown in FIG. 14 may be used to implement source host 1000-S and/or target host 1002-T shown in FIG. 10, and/or device 1404 shown in FIG. 14 may be used to implement source device 1004-S and/or target device 1004-T shown in FIG. 10. However, the embodiment shown in fig. 28 is not limited to the implementation details shown in fig. 10 and/or 14.

The method may begin at operation 2878-1, where a source virtual machine manager 1008-S (which may be referred to as a live migration server) may send a command to a source parent controller 1016A-S (which may be referred to as a live migration controller) instructing the source parent controller 1016A-S to obtain controller state information (which may be referred to as metadata) from a child controller 1016B-S. At operation 2878-2, the source parent controller 1016A-S may read the controller state information 1470 from the source child controllers 1016B-S. At operation 2878-3, the source parent controller 1016A-S may use protection logic 1472 to protect (e.g., encrypt) the controller state information 1470 to generate protected controller state information 1474. At operation 2878-4, the source parent controller 1016A-S may send protected (e.g., encrypted) controller state information 1474 to the source virtual machine manager 1008-S.

At operation 2878-5, the source virtual machine manager 1008-S may send the protected controller state information 1474 to the target virtual machine manager 1008-T, which may be located, for example, at a different location in a data center, a different data center, and/or the like. At operation 2878-6, the target virtual machine manager 1008-T may write protected controller state information 1474 to the target parent controller 1016A-T. At operation 2878-7, the target parent controller 1016A-T may generate unprotected (e.g., decrypted) controller state information 1470 from the protected controller state information 1474 using protection logic 1472. At operation 2878, the target parent controller 1016A-T may configure the target child controller 1016B_T using the unprotected (e.g., decrypted) controller state information 1470 (e.g., by populating the target child controller 1016B_T with the unprotected (e.g., decrypted) controller state information 1470).

Depending on implementation details, the method shown in fig. 28 may enable the state of the sub-controllers to be transferred from the source system to the target system while reducing or eliminating the secure exposure of controller state information. In some embodiments, a header (e.g., for encrypting the controller state information packet) may be used to describe the version, general content, and/or the like of the controller state information.

FIG. 29 illustrates an embodiment of a method for data protection for data migration operations, according to an example embodiment of the present disclosure. For purposes of illustration, the embodiment shown in FIG. 29 may be described in the context of an embodiment in which host 1302 shown in FIG. 13 may be used to implement source host 1000-S and/or target host 1002-T shown in FIG. 10, and/or device 1304 shown in FIG. 13 may be used to implement source device 1004-S and/or target device 1004-T shown in FIG. 10. However, the embodiment shown in fig. 29 is not limited to the implementation details shown in fig. 10 and/or fig. 13.

The method may begin at operation 2978-1, where a source virtual machine manager 1008-S (which may be referred to as a live migration server) may send a command to a source parent controller 1016A-S (which may be referred to as a live migration controller) instructing the source parent controller 1016A-S to obtain user data from a source namespace (e.g., namespace 1-S). At operation 2978-2, the source parent controller 1016A-S may read user data from the source namespace (e.g., user data 1364 having a first protection scheme, as shown in FIG. 13). At operation 2978-3, the source parent controller 1016A-S may replace the first protection scheme with the second protection scheme (e.g., using protection logic 1372) to generate user data 1058 with the second protection scheme (e.g., user data 1380 with the second protection scheme in fig. 13).

At operation 2978-4, the source parent controller 1016A-S may send the user data protected with the second protection scheme to the source virtual machine manager 1008-S. At operation 2978-5, the source virtual machine manager 1008-S may send the user data 1058 protected with the second protection scheme to the target virtual machine manager 1008-T, which may be located in a different location in, for example, a data center, a different data center, and/or the like. At operation 2978-6, the target virtual machine manager 1008-T may send the user data (e.g., 1380 in FIG. 13) protected with the second protection scheme to the target parent controller 1016A-T. At operation 2978-7, the target parent controller 1016A-T may replace the second protection scheme with the first protection scheme (e.g., using protection logic 1366 in FIG. 13) to generate user data (e.g., 1364 in FIG. 13) protected with the first protection scheme. At operation 2978-8, the target parent controller 1016A-T may write the user data (e.g., 1364 in FIG. 13) protected with the first protection scheme to the target namespace (e.g., namespaces 1-T).

For purposes of illustration, the method shown in FIG. 29 may be described in the context of an embodiment in which the host 1302 shown in FIG. 13 may be used to implement the source host 1000-S and/or target host 1002-T shown in FIG. 10, and/or the device 1304 shown in FIG. 13 may be used to implement the source device 1004-S and/or target device 1004-T shown in FIG. 10. In some other embodiments, host 1202 shown in FIG. 12 may be used to implement source host 1000-S and/or target host 1002-T shown in FIG. 10, and/or device 1204 shown in FIG. 12 may be used to implement source device 1004-S and/or target device 1004-T shown in FIG. 10. In such an embodiment, one or more of the parent controllers 1016A-S and/or 1016A-T (e.g., 1216A in FIG. 12) may include protection logic (e.g., 1266 in FIG. 12) that may use the transfer path (e.g., 1276 in FIG. 12) to transfer the protected data.

Some data migration schemes according to example embodiments of the present disclosure may use one or more techniques to achieve compatible protection (e.g., encryption and/or decryption) at the source system and/or the target system. For example, some embodiments may implement a common encryption engine type (e.g., advanced Encryption Standard (AES) 128, 256, and/or the like) with patterns (e.g., patterns that may use exclusive or (XOR), such as XOR Encryption XOR (XEX), XEX trimmable block ciphers with ciphertext stealing (XTS), galois/counter patterns (GCM), cipher Block Chaining (CBC), and/or the like), trimming, salt values (e.g., using LBAs attached to the data being encrypted), keys per IO, and/or the like in some or all implementations. Such embodiments may be implemented, for example, by assuming, requiring that one or more systems use the same or compatible encryption techniques, and/or the like. Additionally or alternatively, embodiments may be implemented with descriptions (e.g., standardized descriptions) that may specify one or more encryption capabilities, one or more options for one or more encryption capabilities, and/or one or more capabilities for one or more devices (e.g., encryption engine type, capabilities, mode (e.g., keys per IO), options, and/or the like) for one or more devices. In some embodiments, a user (e.g., a host) may perform a check of encryption compatibility of a device that may communicate with the user, accept operation with a compatible device, and/or reject operation with an incompatible device.

As another example, in some embodiments, one or more protection (e.g., encryption) techniques may be implemented in hardware (e.g., FPGA, ASIC, and/or the like), software, firmware, and/or the like, or a combination thereof, e.g., to enable the protection techniques used by the devices to be changed, reconfigured, and/or the like. Depending on implementation details, such embodiments may provide increased compatibility between different devices (e.g., from different vendors). As yet another example, different protection (e.g., encryption) techniques may be used for user data and/or controller state information. Thus, for example, referring to fig. 14, a first encryption technique may be used by protection logic 1460 for user data 1462 sent to namespace 1, while a second, different encryption technique may be used by protection logic 1472 for controller state information 1474. In some example embodiments, one or more of the protection logic 1160, 1260, 1360, 1460, 1166, 1266, 1466, 1372, and/or 1472 may be implemented with an encryption and/or decryption engine (e.g., a commercially available encryption and/or decryption engine) that may be controlled, configured (e.g., for a particular type and/or mode of encryption and/or decryption) and/or the like by a monitoring circuit (e.g., a processor, logic circuit, and/or the like), e.g., under control of software, firmware, and/or the like.

Any of the functions disclosed herein, including, for example, any controller, processing path, protection logic, or any other logic and/or functionality implemented at a host, device, and/or the like, may be implemented in hardware, software, firmware, or any combination thereof, including combinational logic, sequential logic, one or more timers, counters, registers, and/or state machines, one or more complex programmable logic devices CPLD, FPGA, ASIC, central processing units (such as Complex Instruction Set Computer (CISC) processors (e.g., x86 processors), and/or Reduced Instruction Set Computer (RISC) processors (such as ARM processors), graphics Processing Units (GPUs), neural Processing Units (NPUs), tensor Processing Units (TPUs), data Processing Units (DPUs), and/or combinations thereof.

In some embodiments, and depending on implementation details, a namespace identification scheme in accordance with example embodiments of the present disclosure may implement and/or provide any number of the following features. The local namespace identifier may be used by one or more sub-controllers (e.g., secondary controllers) for normal input and/or output (I/O) operations. For example, one or more commit queue entries (SQEs) may use a local namespace identifier (e.g., at all times). The global namespace identifier may be used by one or more parent controllers (e.g., a parent controller that may be indicated as PF 0). In some embodiments, one or more promoted secondary controllers (e.g., virtual functions and/or physical functions) may also use the global namespace identifier. In some embodiments, one or more promoted secondary controllers may use one or more global namespace identifiers, e.g., with one or more management queues. One or more I/O queues for these controllers may use the local namespace identifier for a particular sub-controller. For example, the promoted secondary controllers may read and/or write and use one or more normal I/O nonvolatile memory (NVM) commit queues (SQ) for their own attached storage space. In some embodiments, one or more elevated secondary controllers may use the management queue (and in some embodiments may not use one or more hardware accelerations) to perform one or more operations with the stored data of another controller. In other embodiments, the promoted secondary controller may use (e.g., always use) the global namespace identifier. Depending on implementation details, such use of the global namespace identifier may enable the hardware auto-path of the parent controller and/or the promoted controller to access the namespaces of the child controllers (NSe) at hardware accelerated speeds. Depending on implementation details, this may result in a read and/or write of child namespace data, which may be unobstructed and still be correctable to the corresponding global namespace identifier. In some embodiments, for example, during a migration operation, a namespace identification scheme in accordance with example embodiments of the present disclosure may be used for some, most, or each access.

Fig. 30 illustrates an example embodiment of a user device according to an example embodiment of the present disclosure. The user device shown in fig. 30 may be used, for example, to implement any user functionality associated with the namespace identifier schemes, data protection schemes, data migration schemes, and/or the like disclosed herein. The user device 3000 shown in fig. 30 may be implemented with a host, another device, and/or the like. The host may be implemented, for example, with any component or combination of components including one or more of a client device, a server, a storage node, a CPU, a personal computer, a tablet computer, a smart phone, and/or the like.

The user device 3000 shown in fig. 30 may include a processor 3002, and the processor 3002 may include a memory controller 3004, a system memory 3006, user logic 3008, and/or a communication interface 3010. Any or all of the components shown in fig. 30 may communicate over one or more system buses 3012. In some embodiments, one or more of the components shown in fig. 30 may be implemented using other components. For example, in some embodiments, user logic 3008 may be implemented by processor 3002 executing instructions stored in system memory 3006 or other memory. In some embodiments, according to example embodiments of the present disclosure, user logic 3008 may implement any of the user functions disclosed herein, including, for example, one or more hosts, virtual machines, virtual machine managers, and/or the like that may use a namespace identification scheme, data protection (e.g., encryption), data migration, and/or the like.

Fig. 31 shows an example embodiment of an apparatus according to an example embodiment of the present disclosure. The embodiment illustrated in fig. 31 may be used to implement any device functionality associated with the namespace identification, data protection, data migration, and/or the like disclosed herein. Device 3160 may include a device controller 3162, device logic 3130, device functional circuitry 3166, and a communication interface 3110. The components shown in FIG. 31 may communicate via one or more device buses 3112.

Device functional circuitry 3166 may include any hardware for implementing the primary functions of device 3160. For example, if device 3160 is implemented as a storage device, device functional circuitry 3166 may include storage media such as one or more flash memory devices, FTLs, and/or the like. As another example, if device 3160 is implemented as a Network Interface Card (NIC), device functional circuitry 3166 may include one or more modems, network interfaces, physical layers (PHYs), medium access control layers (MACs), and/or the like. As yet another example, if the device 3160 is implemented as an accelerator, the device functional circuitry 3166 may include one or more accelerator circuits, memory circuits, and/or the like.

In some embodiments, any device functions (e.g., device resources) implemented with device function circuitry 3166 may be configured as one or more namespaces. In some embodiments, device logic 3130 may be used to implement any of the disclosed functionality related to the namespace identifications disclosed herein, including, for example, implementing a controller that may access namespaces based on receiving global and/or local namespace identifiers (as shown, for example, with respect to fig. 2, 3, and/or 4), processing namespaces (as shown, for example, with respect to fig. 6 and/or 7), and/or the like. In some embodiments, device logic 3130 may be used to implement any of the functions disclosed in connection with the data protection (e.g., encryption), data migration, and/or the like disclosed herein, including, for example, implementing a controller that may send migration data (e.g., user data, controller state information, and/or the like) in a protected form, as shown, for example, with respect to fig. 10-26.

FIG. 32 illustrates an embodiment of a method for accessing a namespace in accordance with an example embodiment of the present disclosure. The method may begin at operation 3202. At operation 3204, the method may perform, by a controller at the device, a first access to a namespace of the device using the first namespace identifier. The controller may be implemented, for example, by a sub-controller, such as sub-controllers 216B, 316B, and/or 416B as shown in fig. 2, 3, and/or 4. The first namespace identifier can be implemented, for example, with a local namespace identifier (such as local namespace identifiers 214B, 314B, and/or 414B as shown in fig. 2, 3, and/or 4). At operation 3206, the method may perform a second access to a namespace of the device using the second namespace identifier. The second access may be performed, for example, by a parent controller (such as parent controllers 216A, 316A, and/or 416A as shown in fig. 2, 3, and/or 4).

The second namespace identifier can include first information for determining the first namespace identifier and second information for identifying the controller. For example, the first information and the second information may be implemented with local namespace identifiers, and the controller identifiers may be implemented with controller identifiers 217B, 317B, and/or 417B shown in fig. 2, 3, and/or 4, respectively. The method may end at operation 3208.

Fig. 33 illustrates an embodiment of a method for protecting data for a data transfer operation according to an example embodiment of the present disclosure. The method may begin at operation 3302. At operation 3304, the method may receive data at a device using a first controller. For example, a sub-controller (such as sub-controller 1216B) may receive data 1258, as shown in fig. 12. At operation 3306, the method may apply, at the device, a first protection scheme to the data. For example, the sub-controller 1216B shown in fig. 12 may apply one or more of the first protection schemes shown in fig. 16-25 (e.g., encryption, salt, and/or the like). At operation 3308, the method may transmit data having a second protection scheme from the device using a second controller. For example, parent controller 1216A may send data 1264 protected with a second protection scheme, as shown in fig. 12. The method may end at operation 3310.

The embodiments shown in fig. 32 and 33, as well as all other embodiments described herein, are example operations and/or components. In some embodiments, some operations and/or components may be omitted and/or other operations and/or components may be included. Furthermore, in some embodiments, the temporal and/or spatial order of operations and/or components may vary. Although some components and/or operations may be shown as separate components, in some embodiments, some components and/or operations shown separately may be integrated into a single component and/or operation and/or some components and/or operations shown as a single component and/or operation may be implemented with multiple components and/or operations.

Some embodiments disclosed above have been described in the context of various implementation details, but aspects of the disclosure are not limited to these or any other specific details. For example, some functions have been described as being implemented by certain components, but in other embodiments, functions may be distributed among different systems and components located in different locations and having various user interfaces. Certain embodiments have been described as having particular processes, operations, and/or the like, but these terms also encompass embodiments in which a particular process, operation, and/or the like can be implemented with multiple processes, operations, and/or the like, or embodiments in which multiple processes, operations, and/or the like can be integrated into a single process, step, and/or the like. References to a component or element may refer to only a portion of the component or element. For example, a reference to a block may refer to an entire block or one or more sub-blocks. The use of terms such as "first" and "second" in the present disclosure and claims may be used solely for the purpose of distinguishing between their modified elements and may not indicate any spatial or temporal order unless it is not explicitly so apparent from the context. In some embodiments, a reference to an element may refer to at least a portion of the element, e.g., "based on" may refer to "based at least in part on" and/or the like. The reference to the first element may not imply the presence of the second element. The aspects disclosed herein have independent utility and may be embodied separately and not every embodiment may utilize every aspect. However, aspects of the disclosure may also be embodied in various combinations, some of which may synergistically amplify the benefits of the various aspects. The various details and embodiments described above may be combined to produce additional embodiments in accordance with aspects of the present patent disclosure.

Since the inventive principles of this patent disclosure may be modified in arrangement and detail without departing from the inventive concepts, such changes and modifications are considered to be within the scope of the appended claims.

Claims

1. An apparatus, comprising:

an apparatus, comprising:

a first controller; and

a second controller;

wherein the device is configured to:

receiving data using a first controller;

applying a first protection scheme to the data; and is also provided with

Data having a second protection scheme is transmitted from the device using a second controller.

2. The apparatus of claim 1, wherein the first protection scheme and the second protection scheme are the same.

3. The apparatus of claim 1, wherein the second controller is configured to apply a second protection scheme to the data.

4. The apparatus of claim 1, wherein the first protection scheme comprises a salt value.

5. The apparatus of claim 4, wherein the salt is a first salt and the second protection scheme comprises a second salt.

6. The apparatus of claim 5, wherein:

the first salt value is determined by the apparatus; and is also provided with

The second salt value is determined by the user.

7. The apparatus of claim 6, wherein the first protection scheme is based on a first key associated with the first request and a second key associated with the second request.

8. The apparatus of claim 1, wherein the first protection scheme is based on a first key associated with the first request and a second key associated with the second request.

9. The apparatus of claim 1, wherein:

the first protection scheme includes a first type of encryption; and

the second protection scheme includes a second type of encryption.

10. The apparatus of claim 1, wherein the device is configured to apply a third protection scheme to the controller state information of the first controller to generate controller state information having the third protection scheme.

11. The apparatus of claim 10, wherein the second controller is configured to transmit controller state information from the device with a third protection scheme.

12. The apparatus of claim 11, wherein the third protection scheme is the same as the first protection scheme or the second protection scheme.

13. The apparatus of claim 1, wherein the data is first data and the device is configured to:

receiving, using a second controller, second data having a second protection scheme; and

the first protection scheme is applied to the second data.

14. A method, comprising:

receiving data at a device using a first controller;

Applying a first protection scheme to the data at the device; and

15. The method of claim 14, wherein the first protection scheme and the second protection scheme are the same.

16. The method of claim 14, further comprising: at the device, a second protection scheme is applied to the data using a second controller.

17. The method of claim 14, further comprising:

at the device, a third protection scheme is applied to the controller state information of the first controller to generate controller state information having the third protection scheme.

18. The method of claim 17, further comprising: controller status information having a third protection scheme is transmitted from the device using a second controller.

19. An apparatus, comprising:

an apparatus, comprising:

a first controller; and

a second controller;

wherein the device is configured to:

receiving, using a first controller, first data;

applying a first protection scheme to the first data;

generating second data based on the first data; and is also provided with

Second data having a second protection scheme is transmitted from the device using a second controller.

20. The apparatus of claim 19, wherein the device is configured to:

generating first data having a first protection scheme; and

second data having a second protection scheme is generated by performing an operation on the first data having the first protection scheme.