Accessing multiple physical partitions of a hardware device

Abstract

In a computing device, hardware devices (e.g., parallel-accelerated processors or graphics processing units) are coupled to a bus, such as a Peripheral Component Interconnect Express bus (PCIe bus). The hardware device supports physical partitioning, which allows the physical resources of the hardware device to be separated into different partitions. Examples of physical resources include engine resources (e.g., compute resources, direct memory access resources), memory resources (e.g., random access memory), etc. Each physical partition is mapped to a physical function exposed to a host on the computing device in a manner that conforms to the bus protocol, allowing software to access the physical partition in a conventional manner based on the bus protocol.

Description

[Technical Field]

[0001] (Related Applications) This application claims priority to U.S. patent application Ser. No. 18 / 066,155, filed Dec. 14, 2022, entitled "Accessing Multiple Physical Partitions of a Hardware Device," the entire disclosure of which is incorporated herein by reference. [Background technology]

[0002] Modern computer systems provide a wide range of functionality. One way they provide this functionality is through the use of various devices coupled to one or more processors in the computer system, such as through a Peripheral Component Interconnect Express (PCIe or PCI-e) bus.

[0003] The detailed description will be made with reference to the accompanying drawings, in which entities depicted in the figures represent one or more entities, and therefore references will be made interchangeably in the description to one or more aspects of the entities. [Brief explanation of the drawings]

[0004] [Figure 1] FIG. 1 is a diagram of a non-limiting exemplary system operable to employ access to multiple physical partitions of a hardware device as described herein. [Figure 2] FIG. 2 is a diagram of another non-limiting exemplary system operable to employ access to multiple physical partitions of a hardware device as described herein. [Figure 3] FIG. 2 is a diagram of a correspondence between software partitions and physical partitions, according to one or more embodiments. [Figure 4] FIG. 10 is another diagram of the correspondence between software partitions and physical partitions, according to one or more embodiments. [Figure 5] FIG. 1 is a flow diagram illustrating a procedure in an example embodiment for accessing multiple physical partitions of a hardware device. DETAILED DESCRIPTION OF THE INVENTION

[0005] (overview) In a computing device, a hardware device (e.g., a parallel-accelerated processor or a graphics processing unit (GPU)) is coupled to a bus, such as a PCIe bus. The hardware device supports physical partitioning, which allows the physical resources of the hardware device to be separated into different partitions. Examples of such physical resources include engine resources (e.g., compute resources, direct memory access (DMA) resources), memory resources (e.g., random access memory (RAM)), etc. Each physical partition is mapped to a physical function exposed to a host on the computing device in a manner that conforms to the protocol of the bus (e.g., a PCIe bus), allowing software to access the physical partition in a conventional manner based on the protocol of the bus.

[0006] The techniques described herein operate in a bare-metal environment and allow software on a computing device to access different physical partitions of a hardware device (through mappings to physical functions) without having a hypervisor running on the computing device. Furthermore, the techniques described herein allow functions of a hardware device to be shared by multiple pieces of software simultaneously. By using different physical partitions, it is not necessary to use time-sharing for different pieces of software to use the hardware device. Rather, different physical partitions can run simultaneously, each performing operations for different pieces of software.

[0007] In some aspects, the techniques described herein relate to a method that includes exposing a physical function of a hardware device on a bus, the physical function corresponding to one of multiple physical partitions of the hardware device; receiving a request to perform one or more operations via the physical function; and performing the one or more operations on the physical partition.

[0008] In some aspects, the technology described herein relates to a method, wherein the bus comprises a Peripheral Component Interconnect Express bus.

[0009] In some aspects, the techniques described herein relate to a method further including exposing additional physical functions of the hardware device on the bus, the additional physical functions corresponding to a device management module of the hardware device that manages multiple physical partitions of the hardware device.

[0010] In some aspects, the techniques described herein relate to a method further including receiving configuration information corresponding to software, the configuration information indicating resources required for execution of the software, and configuring a physical partition to include the indicated resources based on the received configuration information.

[0011] In some aspects, the technology described herein relates to how the software comprises a software container, an application, or a software stack.

[0012] In some aspects, the techniques described herein relate to a method further including exposing an additional physical function of a hardware device on a bus, the additional physical function corresponding to an additional physical partition of a plurality of physical partitions; receiving a request to perform at least one operation via the additional physical function; and performing the at least one operation on the additional physical partition.

[0013] In some aspects, the techniques described herein relate to methods in which requests are received from software through a kernel-mode driver on the host, rather than through a hypervisor.

[0014] In some aspects, the technology described herein relates to a device that includes physical functions exposeable on a bus coupled to the device for receiving requests to perform one or more operations, and a physical partition corresponding to the physical functions for performing the one or more operations, the physical partition being any of multiple physical partitions of the device.

[0015] In some aspects, the technology described herein relates to a device, wherein the bus comprises a Peripheral Component Interconnect Express bus.

[0016] In some aspects, the technology described herein relates to a device further including additional physical functions that can be exposed on a bus, and a device management module that corresponds to the additional physical functions and manages multiple physical partitions of the device.

[0017] In some aspects, the techniques described herein relate to a device in which a device management module is to receive, via a bus and an additional physical function, configuration information corresponding to software, the configuration information indicating resources required for execution of the software, and configure a physical partition including the indicated resources based on the received configuration information.

[0018] In some aspects, the techniques described herein relate to a device in which configuration information is received from a management application that provides an interface for managing resources within the device.

[0019] In some aspects, the technology described herein relates to a device that further includes an additional physical function exposeable on a bus for receiving a request to perform at least one operation, and an additional physical partition corresponding to the additional physical function for performing the at least one operation, where the additional physical partition is any of a plurality of physical partitions.

[0020] In some aspects, the techniques described herein relate to devices where requests are received from software through a kernel-mode driver on the host rather than through a hypervisor.

[0021] In some aspects, the technology described herein relates to a computing device that includes a bus and a hardware device coupled to the bus, the hardware device including physical functions exposed on the bus for receiving requests to perform one or more operations via the bus, the hardware device further including physical partitions corresponding to the physical functions for performing the one or more operations, the physical partitions being any of multiple physical partitions of the hardware device.

[0022] In some aspects, the technology described herein relates to a computing device, wherein the bus comprises a Peripheral Component Interconnect Express bus.

[0023] In some aspects, the technology described herein relates to a computing device further including additional physical functions exposed on a bus and a device management module corresponding to the additional physical functions and managing multiple physical partitions of the hardware device.

[0024] In some aspects, the techniques described herein relate to a computing device in which a device management module is to receive, via a bus and an additional physical function, configuration information corresponding to software, the configuration information indicating resources required for execution of the software, and configure a physical partition including the indicated resources based on the received configuration information.

[0025] In some aspects, the technology described herein relates to a computing device further including an additional physical function exposed on a bus for receiving a request to perform at least one operation, and an additional physical partition corresponding to the additional physical function for performing the at least one operation, where the additional physical partition is any of a plurality of physical partitions.

[0026] In some aspects, the techniques described herein relate to a computing device in which requests are received from software through a kernel-mode driver of a host rather than through a hypervisor.

[0027] 1 is a diagram of a non-limiting exemplary system 100 operable to employ access to multiple physical partitions of a hardware device as described herein. System 100 includes a processor 102, a hardware device 104, and a bus 106. Processor 102 includes one or more cores. While a single processor 102 is shown, additionally or alternatively, system 100 may include one or more processors of the same type as processor 102 or of different types from processor 102.

[0028] Bus 106 may be any of a variety of high-speed buses. In one or more embodiments, bus 106 is a PCIe bus.

[0029] The hardware device 104 may be any of a variety of physical devices that can be coupled to the bus 106, such as a GPU, a parallel-accelerated processor, an input / output (I / O) device, etc. The hardware device 104 includes multiple (N) physical partitions 108(1),...,108(N). Each physical partition 108 includes one or more engine resources, such as a computational resource (e.g., a processor core or processor cluster), a DMA engine, etc. These engine resources are shown as engine resources 110(1),...,110(N) within the hardware device 104. Each physical partition 108 also includes one or more memory resources, such as RAM, a memory channel (e.g., a channel to system memory external to the hardware device 104), etc. These memory resources are shown as memory resources 112(1),...,112(N) within the hardware device 104.

[0030] Each physical partition also includes one or more registers that store data or information used by one or more of the engine resources within the physical partition, shown as registers 114(1),..., 114(N).

[0031] The hardware device 104 also includes an interconnect 116 (e.g., a network on chip (NoC)) that allows a management function 118 to communicate information to and from physical partitions or management control modules, as described in more detail below.

[0032] Hardware device 104 exposes multiple physical functions on bus 106. Exposing a physical function on bus 106 refers to making the physical function accessible to applications running on processor 102, such as by publishing a name, address, or other identifier of the physical function, which is then used by the application to send data or instructions to or receive data or instructions from the physical partition corresponding to the physical function. Physical functions support a complete configuration space (e.g., configuration space registers) and therefore operate without requiring a hypervisor running on the device implementing system 100. Physical functions differ from virtual functions in that physical functions support a complete configuration space within hardware device 104, whereas virtual functions rely on a hypervisor running on the device implementing system 100 to build a complete configuration space (e.g., configuration space registers). Each physical partition 108 corresponds to a physical function, as described in more detail below.

[0033] In one or more implementations, physical partitions 108 are configurable and can change over time. For example, at one time, a particular physical partition 108 includes one set of engine resources 110 and memory resources 112, and at another time, that same particular physical partition includes a different set of engine resources 110 and memory resources 112. This allows physical partitions to change and adapt according to the needs or requirements of software executing on processor 102.

[0034] System 100 may be implemented in any of a variety of different types of computing devices. For example, system 100 may be implemented in a server, a desktop computer, a smartphone or other wireless phone, a tablet or phablet computer, a notebook computer (e.g., a netbook or ultrabook), a laptop computer, a wearable device (e.g., a smartwatch, an augmented reality headset or device, a virtual reality headset or device), an entertainment device (e.g., a game console, a portable gaming device, a streaming media player, a digital video recorder, a music or other audio playback device, a television), an Internet of Things (IoT) device, an automotive computer, etc.

[0035] 2 is a diagram of another non-limiting exemplary system 200 operable to employ access to multiple physical partitions of a hardware device as described herein. System 200 includes hardware device 202, host 204, software 206, software 208, and software 210. Each of software 206, software 208, and software 210 may also be referred to as different software that includes one or more programs. Hardware device 202 is, for example, hardware device 104 of FIG. 1. System 200 may be implemented in any of a variety of different types of computing devices, such as any of the types of computing devices described above with reference to system 100 of FIG. 1.

[0036] Each of the software 206, 208, and 210 may take any of a variety of different forms. Examples of software 206, 208, and 210 include applications, containers, operating systems, drivers, software stacks (e.g., sets of software that work together to support the execution of an application), combinations thereof, and the like. A container, also referred to as a software container, contains one or more applications along with any libraries, frameworks, dependencies, user-mode drivers, other binaries, configuration files, and the like used to run the one or more applications. A container shares the kernel of a computing device's host operating system with other containers running within the computing device. Thus, a container executes independently of and without the need for a hypervisor.

[0037] In system 200, each piece of software 206, 208, 210 is a software container that optionally includes one or more applications and user-mode drivers. Software 206, 208, 210 share the kernel of a host operating system, host 204. Host 204 includes kernel-mode drivers 224, 226, 228 that correspond to the pieces of software 206, 208, 210, respectively. Software 206, 208, 210 communicate with kernel-mode drivers 224, 226, 228, enabling the pieces of software 206, 208, 210 to send requests to and receive responses from the physical partitions of hardware devices 202 that correspond to the pieces of software 206, 208, 210, as described in more detail below.

[0038] Hardware device 202 includes physical partition 230, physical partition 232, and physical partition 234. While three physical partitions are shown in hardware device 202, it should be understood that hardware device 202 optionally includes a fewer or greater number of physical partitions. Physical partitions 230, 232, and 234 include dedicated memory resources 236, 238, and 240, respectively, and engine resources 242, 244, and 246, respectively, and registers 248, 250, and 252, respectively. Physical partitions 230, 232, 234, memory resources 236, 238, and 240, engine resources 242, 244, and 246, and registers 248, 250, and 252 are similar to the physical partitions, memory resources, engine resources, and registers described above with reference to FIG. 1 .

[0039] Each physical partition 230, 232, 234 corresponds to a physical function 254, 256, 258, respectively. Each physical function 254, 256, 258 is exposed on a bus (e.g., bus 106 in FIG. 1 ) to allow software 206, 208, 210 to access one of the physical partitions. In system 200, software 206 accesses physical partition 230 via kernel-mode driver 224 and physical function 254. Similarly, software 208 accesses physical partition 232 via kernel-mode driver 226 and physical function 256. Similarly, software 210 accesses physical partition 234 via kernel-mode driver 228 and physical function 258.

[0040] Thus, rather than having a single physical function corresponding to the entirety of hardware device 202 (e.g., a parallel acceleration processor or GPU), the functionality of hardware device 202 is separated into multiple physical partitions. For example, hardware device 202 has multiple (e.g., three different) parallel acceleration processors or GPUs exposed to and available for use by software 206, 208, 210.

[0041] Hardware device 202 also includes a device management (Mng.) module 260 and resource map and management control modules corresponding to the physical partitions. These resource map and management control modules are shown as resource map and management control 262 corresponding to physical partition 230, resource map and management control 264 corresponding to physical partition 232, and resource map and management control 266 corresponding to physical partition 234. The resource map and management control modules corresponding to the physical partitions identify resources (e.g., dedicated memory resources, engine resources, and registers) within the corresponding physical partition. The resources within a particular physical partition 230, 232, or 234 are configurable by device management module 260.

[0042] Hardware device 202 also includes a physical function 268 that is exposed on a bus (e.g., bus 106 in FIG. 1 ) similar to physical functions 254, 256, and 258. Physical function 268 is, for example, management function 118 in FIG. 1 . Upon initialization of system 200, physical function 268 is exposed on the bus, followed by subsequent exposure of physical functions 254, 256, and 258. This allows device management module 260 to receive configuration information for different physical functions and corresponding physical partitions via physical function 268 and configure resources of the physical partitions and corresponding physical functions, after which physical functions 254, 256, and 258 are exposed on the bus.

[0043] Physical functions 268 correspond to function drivers 270 in host 204, which together allow configuration information to be communicated to device management module 260. The configuration information indicates which resources are to be used by software 206, 208, or 210. These resources may be specified in any of a variety of ways, such as by explicitly identifying the resources (e.g., by identifying a particular engine resource, by identifying a particular memory channel or amount of memory, etc.). Additionally or alternatively, these resources may be specified implicitly, such as by a particular performance requirement, which allows device management module 260 to determine the resources to allocate to software 206, 208, or 210.

[0044] In one or more embodiments, device management module 260 receives configuration information from management (Mng.) application 272. A kernel-mode driver (e.g., function driver 270 or another kernel-mode driver) discovers and reports the resources and capabilities of hardware device 202 during initialization time. Management application 272 receives this information describing the resources and capabilities of hardware device 202, determines which physical partitions should be configured with which resources, and sends an indication of which physical partitions should be configured with which resources to device management module 260 via function driver 270 and physical function 268. Device management module 260 communicates with resource maps and management controls 262, 264, 266 and corresponding physical functions 254, 256, 258 to configure resources for physical partitions 230, 232, 234. Management application 272 determines which physical partitions should be configured with which resources in any of a variety of ways, for example, based on input from a user or administrator of the device implementing system 200, the resources required for the software (e.g., software container) being launched (e.g., as indicated in metadata or setup data associated with the software), etc. Thus, management application 272 provides an interface for managing resources within hardware device 202.

[0045] Additionally or alternatively, device management module 260 receives configuration information from other sources, such as directly from host 204 (e.g., configuration information is included as metadata or setup data associated with software 206, 208, or 210 when the software begins execution within system 200).

[0046] Resource map and management control 262 maintains a record of the resources that make up physical partition 230. Based on the received configuration information for software 206, device management module 260 determines which resources to allocate to physical partition 230 and provides an indication of those resources to resource map and management control 262. Resource map and management control 262 creates physical partition 230 that includes the resources indicated by device management module 260.

[0047] Similarly, resource map and management control 264 maintains a record of the resources that make up physical partition 232. Based on the received configuration information for software 208, device management module 260 determines which resources to allocate to physical partition 232 and provides an indication of those resources to resource map and management control 264. Resource map and management control 264 creates physical partition 232 that includes the resources indicated by device management module 260.

[0048] Similarly, resource map and management control 266 maintains a record of the resources that make up physical partition 234. Based on the received configuration information for software 210, device management module 260 determines which resources to allocate to physical partition 234 and provides an indication of those resources to resource map and management control 266. Resource map and management control 266 creates physical partition 234 that includes the resources indicated by device management module 260.

[0049] Resource map and management controls 262, 264, 266 also restrict access to resources in the corresponding physical partitions to the corresponding physical functions. This provides security for the operational information used in the physical partitions because requests received by a physical function that does not correspond to a physical partition cannot access that physical partition. For example, resource map and management controls 264 restricts access to physical partition 232 to physical function 256 and ignores or otherwise prevents any requested operations received by physical function 254 or physical function 258 from being performed by physical partition 232.

[0050] In one exemplary embodiment, hardware device 202 is coupled to a PCIe bus that supports exposing up to eight physical functions on the PCIe bus. In this example, physical function 268 (e.g., exposed by hardware device 202 on the PCIe bus as physical function 0) is mapped to device management module 260, and physical functions 254, 256, and 258 (e.g., exposed by hardware device 202 on the PCIe bus as physical function 4, physical function 5, and physical function 6, respectively) are each mapped to one of three different partitions on hardware device 202.

[0051] Physical partitions are dynamic and can change over time. For example, in one or more embodiments, when software stops executing or is no longer needed, resources within the physical partition that was running the software are freed and can be allocated to one or more new physical partitions. Additionally or alternatively, resources are not freed but made available for newly executing software.

[0052] In one or more embodiments, device management module 260 combines resources in two or more physical partitions to create a single larger partition (corresponding to the physical function of one of the two or more physical partitions). For example, if two physical partitions are established but are not currently running software, and new software is launched that requires more resources than either of the two physical partitions has, device management module 260 combines the resources of the two physical partitions into a single physical partition and coordinates with the resource map and management control module corresponding to the single physical partition.

[0053] In one or more embodiments, device management module 260 has full access to the resources of the computing device to configure and manage physical partitions. However, physical functions corresponding to physical partitions have lower privileges and are restricted to access only the resources assigned to their corresponding physical partitions (e.g., as indicated by the resource map and management control module). Furthermore, physical functions cannot change settings in the resource map and management control module. Rather, the ability to change settings in the resource map and management control module is reserved for device management module 260.

[0054] Figure 3 is a diagram of a correspondence between software partitions and physical partitions, according to one or more embodiments. In example 300 of Figure 3, references are made to elements of Figure 2. As shown, hardware device 202 includes physical partition 230, physical partition 232, and physical partition 234, each with corresponding physical function 254, physical function 256, and physical function 258. Example 300 also includes software 206, software 208, and software 210 (e.g., executing on processor 102 of Figure 1).

[0055] Software 206 is mapped to physical function 254 and therefore executes on physical partition 230. Software 208 is mapped to physical function 256 and therefore executes on physical partition 232. Software 210 is mapped to physical function 258 and therefore executes on physical partition 234.

[0056] Additionally, as described above, each piece of software 206, 208, 210 has its own corresponding kernel mode driver 224, 226, 228, respectively, within host 204. Thus, a request to perform an operation from software 206, 208, or 210 is communicated to the physical function and physical partition corresponding to that software, preventing other software from performing the operation on another physical partition. For example, software 208 and software 210 are prevented from performing the operation on physical partition 230.

[0057] Running different software on different physical partitions improves software security: each software runs on a physical partition with its own resources (e.g., memory resources, engine resources, registers), preventing software running on one physical partition from accessing the resources of another partition.

[0058] Furthermore, running different software on different physical partitions improves the performance of the hardware device 202. Different physical partitions have different resources, and therefore multiple software programs can run simultaneously on different physical partitions without having to waste time and resources running time-shares of the same resources.

[0059] While example 300 shows three different pieces of software 206, 208, 210, each corresponding to and executing on a different physical partition 230, 232, 234, it should be noted that, additionally or alternatively, multiple pieces of software may perform operations on the same physical partition. As an example, software 206 shares physical partition 230 with additional software, such that the two pieces of software are mapped to the same physical function (e.g., physical function 254) and execute on the same physical partition (e.g., physical partition 230).

[0060] Figure 4 is another diagram of the correspondence between software partitions and physical partitions, according to one or more embodiments. Example 400 in Figure 4 references elements from Figure 2. Example 400 is similar to example 300 in Figure 3, except that a single piece of software 206 owns or possesses all of the resources of hardware device 202.

[0061] As shown, hardware device 202 includes a single physical partition 402 with corresponding physical function 254. Example 400 also includes software 206, software 208, and software 210 (e.g., executing on processor 102 of FIG. 1).

[0062] Software 206 is mapped to physical functions 254 and therefore executes on physical partition 402. Physical partition 402 includes dedicated memory resources 236, 238, 240, engine resources 242, 244, 246, and registers 248, 250, 252. Thus, the dedicated memory resources, engine resources, and registers that were divided across three different device physical partitions in example 300 of Figure 3 are assigned to a single physical partition 402 in Figure 4.

[0063] Additionally, as described above, each piece of software 206, 208, 210 has its own corresponding kernel mode driver 224, 226, 228, respectively, within host 204. Thus, a request to perform an operation from software 206, 208, or 210 is communicated to the physical function and physical partition corresponding to that software, preventing other software from performing the operation on another physical partition. For example, software 208 and software 210 are prevented from performing the operation on physical partition 402.

[0064] Hardware device 202 includes physical function 256 and physical function 258, but there are no physical partitions associated with physical functions 256 and 258, and there are no resources mapped to physical functions 256 and 258. Therefore, software 208 and 210 cannot use the functions of hardware device 202.

[0065] The techniques described herein operate in a bare-metal environment and allow multiple pieces of software on a computing device to access different physical partitions of a hardware device (through mappings to physical functions) without having a hypervisor running on the computing device. However, the computing device is configurable, allowing the computing device to run in different configurations (e.g., single root input / output virtualization (SR-IOV) mode) that include a hypervisor, for example, after a reset or reboot. Thus, the techniques described herein do not disturb or interfere with the operation of the hypervisor or with physical functions assigned to different guest virtual machines.

[0066] 5 is a flow diagram 500 illustrating a procedure in an example embodiment for accessing multiple physical partitions of a hardware device. Flow diagram 500 is performed by a hardware device, such as hardware device 104 of FIG. 1 or hardware device 202 of FIG. 2, 3, or 4.

[0067] In this example, a physical function of a hardware device is exposed on a bus (block 502). The physical function corresponds to one of multiple physical partitions of the hardware device.

[0068] A request to perform one or more operations is received via a physical function (block 504). The one or more operations may be received, for example, from software executing on the same computing device as the hardware device.

[0069] One or more operations are performed on the physical partition (block 506).

[0070] The various functional units illustrated in the figures and / or described herein (including, where appropriate, device management module 260, resource map and management control 262, resource map and management control 264, and resource map and management control 266) may be implemented in any of a variety of different ways, such as hardware circuits, software or firmware running on a programmable processor, or any combination of two or more of hardware, software, and firmware. The provided methods may be performed in any of a variety of devices, such as a general-purpose computer, a processor, or a processor core. Suitable processors include, by way of example only, a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a GPU, a parallel-accelerated processor, multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or a state machine.

[0071] In one or more embodiments, the methods and procedures provided herein may be implemented in a computer program, software, or firmware embodied in a non-transitory computer-readable storage medium for execution by a general-purpose computer or processor. Examples of non-transitory computer-readable storage media include read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs).

[0072] (Conclusion) Although the invention has been described in language specific to structural features and / or methodological acts, it is to be understood that the invention as defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed invention.

Claims

1. 1. A method comprising: Exposing a physical function of a hardware device on a bus, the physical function corresponding to one of a plurality of physical partitions of the hardware device; receiving, via the physical function, a request to perform one or more operations; executing the one or more operations on any of the physical partitions; method.

2. the bus includes a Peripheral Component Interconnect Express bus; 10. The method of claim 1.

3. exposing an additional physical function of the hardware device on a bus, the additional physical function corresponding to a device management module of the hardware device that manages the plurality of physical partitions of the hardware device; 10. The method of claim 1.

4. receiving configuration information corresponding to software, the configuration information indicating resources required to execute the software; and configuring the physical partition to include the indicated resources based on the received configuration information. The method of claim 3.

5. The software includes a software container, an application, or a software stack. The method of claim 4.

6. exposing an additional physical function of the hardware device on a bus, the additional physical function corresponding to an additional physical partition of the plurality of physical partitions; receiving a request to perform at least one operation via said additional physical function; performing the at least one operation on the additional physical partition.

10. The method of claim 1.

7. the request is received from software via a kernel mode driver on the host, rather than via a hypervisor; 10. The method of claim 1.

8. A device, a physical function exposable on a bus coupled to said device for receiving requests to perform one or more operations; a physical partition corresponding to the physical function for performing the one or more operations, the physical partition being any one of a plurality of physical partitions of the device; device.

9. the bus includes a Peripheral Component Interconnect Express bus; The device of claim 8.

10. additional physical functions that can be exposed on the bus; a device management module that corresponds to the additional physical function and manages the plurality of physical partitions of the device; The device of claim 8.

11. The device management module receiving, via the bus and the additional physical function, configuration information corresponding to software, the configuration information indicating resources required for execution of the software; configuring the physical partition with the indicated resources based on the received configuration information; configured to: The device of claim 10.

12. the configuration information is received from a management application that provides an interface for managing resources within the device; The device of claim 11.

13. an additional physical function exposable on said bus for receiving a request to perform at least one operation; an additional physical partition corresponding to the additional physical function for performing the at least one operation, the additional physical partition being any one of the plurality of physical partitions; The device of claim 8.

14. the request is received from software via a kernel mode driver on the host, rather than via a hypervisor; The device of claim 8.

15. 1. A computing device comprising: Bus and a hardware device coupled to the bus, the hardware device including physical functions exposed on the bus for receiving requests to perform one or more operations via the bus, the hardware device including physical partitions corresponding to the physical functions for performing the one or more operations, the physical partitions being any of a plurality of physical partitions of the hardware device; Computing devices.

16. the bus includes a Peripheral Component Interconnect Express bus; 16. The computing device of claim 15.

17. additional physical functions exposed on the bus; a device management module that corresponds to the additional physical function and manages the plurality of physical partitions of the hardware device; 16. The computing device of claim 15.

18. The device management module receiving, via the bus and the additional physical function, configuration information corresponding to software, the configuration information indicating resources required for execution of the software; configuring the physical partition with the indicated resources based on the received configuration information; configured to:

20. The computing device of claim 17.

19. an additional physical function exposed on said bus for receiving a request to perform at least one operation; an additional physical partition corresponding to the additional physical function for performing the at least one operation, the additional physical partition being any one of the plurality of physical partitions; 16. The computing device of claim 15.

20. the request is received from software via a kernel mode driver on the host, rather than via a hypervisor; 16. The computing device of claim 15.

Images