Processing Units Reset by Virtual Functions

Abstract

A Virtual Function (VF) [111] of a Virtual Machine [110] is capable of directly resetting a processing portion [106] of a Processing Unit [104]. The VF directly initiates a reset of the processing portion, and host drivers [116] associated with the processing unit are bypassed during the reset process. By enabling a direct reset of the processing portion, the processing system [100] reduces the overhead associated with the reset process, enhances system security, and improves overall VM and hardware isolation in the processing system.

Description

[Background technology]

[0001] To support efficient use of processing resources, some processing systems support virtualization, in which multiple independent processing environments, called virtual machines (VMs), use the processing resources of the processing system. In some cases, the processing system employs one or more virtualization layers that abstract the hardware resources of the processing system, allowing the VMs to use device drivers, application program interfaces (APIs), operating systems, and other software designed and implemented for non-virtualized environments. For example, in some cases, the processing system includes a hypervisor that provides an interface between the hardware resources of the processing system and the running VMs. The hypervisor employs host device drivers that interface with the hardware resources, and the hypervisor translates communication between the VM's local device drivers and the host drivers. Thus, the hypervisor allows the hardware resources of the processing system to appear to the VMs as dedicated local hardware resources, allowing the VMs to use standard device drivers and other software designed for use with local dedicated hardware. However, for some operations, in some processing environments, the additional processing required to virtualize the hardware resources results in processing inefficiencies.

[0002] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings, in which: The use of the same reference numbers in different drawings indicates similar or identical items. [Brief description of the drawings]

[0003] [Figure 1] FIG. 2 is a block diagram of a processing system that supports direct reset of processing portions of a processing unit by a virtual function in accordance with some embodiments. [Diagram 2]2 is a block diagram of a virtual function of the processing system of FIG. 1 for directly resetting a processing portion of a processing unit according to some embodiments. [Diagram 3] 4 is a block diagram illustrating an example of a virtual function for resetting a rendering engine in a graphics processing unit chiplet, in accordance with some embodiments. [Figure 4] FIG. 2 is a flow diagram of a method of a virtual function directly resetting a processing portion of a processing unit according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0004] 1-4 illustrate a technique for enabling a virtual function (VF) of a virtual machine to directly reset a processing portion of a processing unit. The VF directly initiates a reset of the processing portion, and host drivers associated with the processing unit are bypassed during the reset process. By enabling a direct reset of the processing portion, the processing system reduces overhead associated with the reset process, enhances system security, and improves overall VM and hardware isolation in the processing system.

[0005] To illustrate, in some cases, a processing system supports virtualization of hardware resources through partitioning of the hardware resources, such as a graphics processing unit (GPU). The hardware resources are assigned a physical function (PF) that manages operations on the hardware resources. Each VM executing in the processing system is assigned a different VF, and the PF and other virtualization entities in the processing system manage the provision of the hardware resources to the VMs through their respective VFs. That is, the VF provides a way for the corresponding VM to interface with the PF and control the portion of the hardware resource assigned to the VM.

[0006] In some conventional processing systems, hardware resources are partitioned in time among different VFs. Thus, each VF is assigned a portion, also called a "slot," of a given unit of time, and each VF is allowed to control the hardware resource during its assigned time slot. In some circumstances, an error occurs in the hardware resource for a particular VF, such as a stall (or "hang") of the hardware resource when performing operations on behalf of the VF. In response to such an error, the VF typically attempts to reset the hardware resource. However, such a reset often affects operations performed by the hardware resource on behalf of other VFs. Thus, for hardware resources partitioned in time, the VF needs to work with the host driver to reset the hardware resource. In particular, the guest driver interfacing with the VF needs to send an interrupt to the host driver to request a reset, and the host driver identifies which VF sent the request and which partition in time is associated with that VF. The host driver then communicates with the hypervisor or host device's system management unit (SMU) firmware to reset the hardware resources (this communication process is called a "handshake" between the host driver and the SMU firmware). During the reset, no other VFs can run on the host device. After the hardware resource reset is complete, the host driver notifies the guest driver associated with the VF that the reset is complete.

[0007] In contrast to temporally partitioned hardware resources, in some embodiments, hardware resources are partitioned spatially, such that different processing portions of the hardware resources are assigned to different VFs (and thus to different corresponding VMs). For example, in some embodiments, a GPU includes multiple rendering engines, with each rendering engine implemented by a different independent hardware, such as a different GPU chiplet. When hardware resources are partitioned spatially, in at least some cases, resetting one processing portion of the resource does not affect operation in other processing portions. Thus, using the techniques herein, a VF that controls a portion of a spatially partitioned hardware resource can directly reset its assigned processing portion, bypassing the host device driver and simplifying the reset process.

[0008] Furthermore, since the host device driver is bypassed, security in the processing system is enhanced. To illustrate, in a conventional system where all reset requests by a VF are sent to a host driver, a malicious driver or application may send many reset requests. Servicing these multiple requests consumes the bandwidth of the corresponding hardware resources, thus affecting the quality of service of all VMs running in the processing system. Using the techniques described herein, the VF resets its assigned portion of the hardware resources and bypasses the host driver. Thus, issuing multiple reset requests by a VF only affects the VM associated with that VF, and does not affect the quality of service of other VMs.

[0009] 1 is a block diagram of a processing system 100 configured to support direct reset of processing portions of a processing unit by a virtual function, according to some embodiments. The example of FIG. 1 is described with respect to some exemplary embodiments in which the processing unit is a GPU. However, it will be appreciated that in other embodiments, the techniques described herein apply to other types of processing units, such as vector processing units, parallel processing units, machine learning processing units, artificial intelligence processing units, etc.

[0010] The processing system 100 is generally configured to execute a set of instructions, such as a virtual machine (VM), an operating system, an application, etc., such that the processing system performs designated tasks as indicated by the set of instructions on behalf of an electronic device. Thus, in different embodiments, the processing system 100 is incorporated into any of a variety of electronic devices, such as, for example, a server, a desktop computer, a laptop computer, a gaming console, a tablet, a smartphone, etc. To support the execution of the set of instructions, the processing system 100 includes a processor 102 and a processing unit 104. Although the processor 102 and the processing unit 104 are shown as separate blocks, it will be understood that in some embodiments, one or more of the processor 102 and the processing unit 104 are collectively incorporated into a single integrated circuit or integrated circuit package. For example, in some embodiments, the processor 102 and the processing unit 104 are formed from different semiconductor dies, and all of the dies are incorporated into a multi-chip integrated circuit.

[0011] Processor 102 is a general-purpose processor and is generally configured to execute a set of general-purpose instructions. Thus, in some embodiments, processor 102 is a central processing unit (CPU) having one or more processor cores (not shown), each including one or more instruction pipelines configured to execute program threads representing portions of the set of instructions in a pipelined manner. In the course of executing the program threads, the instruction pipelines generate graphics commands (e.g., draw commands) that represent requests for specified graphics operations.

[0012] Processing unit 104 is a processing unit configured to receive commands to perform a particular class or type of operation, and is further configured to perform the corresponding operation indicated by the command. For example, in some embodiments, processing unit 104 is a GPU configured to perform drawing operations, texture operations, shader operations, tessellation operations, vector processing operations, etc. Processing unit 104 includes multiple processing portions, including processing portion 106 and processing portion 108. In some embodiments, processing unit 104 includes additional processing portions not shown in FIG. 1. As used herein, a processing portion of a processing unit is a set of circuitry that collectively performs a processing operation independently or substantially independently of other processing portions. For example, in some embodiments, processing unit 104 is a GPU, and each of processing portions 106 and 108 implements a rendering engine, each rendering engine operating substantially independently of the others to perform graphics operations based on received commands.

[0013] Processing unit 104 also includes one or more local system management units (SMUs), such as SMU 122. SMU 122 is generally a hardware module, software module, or combination thereof configured to manage certain operations of processing unit 104, particularly including reset operations of processing portions 106 and 108. In some embodiments, when processing unit 104 has multiple SMUs 122, each SMU 122 controls one processing portion 106 or 108.

[0014] In the example of FIG. 1, processing system 100 implements a virtualized computing environment, where virtual machines (e.g., VMs 110, 112) execute on the processor, and processing system 100 exposes the system's physical resources to different VMs as if the physical resources were dedicated physical devices accessed by the VMs. For example, in some embodiments, processor 102 is generally configured to virtualize processing unit 104, such that the physical resources of processing unit 104 are employed by multiple VMs simultaneously, but the physical resources appear to each of the multiple VMs as a physical processing unit dedicated to that VM. Furthermore, in at least some embodiments, processor 102 implements virtualization by spatially partitioning the hardware resources of processing unit 104. In particular, the processing unit assigns processing portions 106 and 108 to different virtual machines, such that each VM employs the hardware resources of its assigned processing portion independently of the other VMs.

[0015] To support virtualization, processor 102 includes host device drivers 116 and hypervisor 117. As will be appreciated by those skilled in the art, a host entity (e.g., host device driver or hypervisor) refers to an entity that is controlled by processor 102 to perform operations on behalf of multiple running virtual machines. In contrast, a local entity (e.g., local device driver 118) refers to an entity that is executed and controlled by an individual VM. Thus, the host entity directly controls the hardware resources of processing system 100 and, at least in some cases, controls those hardware resources in response to requests from multiple VMs.

[0016] Hypervisor 117 is a hardware unit, software module, or combination thereof configured to control different hardware resources of processing system 100 and provide an interface between those hardware resources and other modules of processor 102. In particular, hypervisor 117 is configured to control certain reset operations on the hardware resources of processing system 100, including certain reset operations of processing unit 104. For example, in some embodiments, hypervisor 117 is configured to trigger a full reset of processing unit 104 in response to detecting a specified system condition, such as a VM reset.

[0017] The host device driver 116 is a device driver that executes on the processor 102 to provide an interface between modules (hardware or software) of the processor 102 and the processing unit 104. Thus, in at least some embodiments, the host device driver 116 is generally configured to receive communications (e.g., requests for specified operations) from modules of the processor 102, such as the local device driver 118 of the VM 110. The host device driver 116 manages the provision of those communications to the processing unit 104, including ensuring that the communications meet any timing or other communication requirements of the processing unit 104 by converting those communications into a particular format expected by the processing unit 104. The host device driver 116 also manages communications received from the processing unit 104 in response to the communication from the host device driver 116, including converting the received communications into a format expected by the modules of the processor 102.

[0018] To further support access to hardware resources of processing unit 104, processor 102 implements a set of VFs including VF 111 and VF 113. Upon initiation of execution of a VM, processor 102 assigns a corresponding VF to the VM such that each VF is uniquely assigned to a different VM. Thus, in the example of FIG. 1, VM 110 is assigned VF 111 and VM 112 is assigned VF 113.

[0019] Each VM employs a corresponding VF to access the hardware resources of processing unit 104. In particular, as described above, processing system 100 virtualizes the hardware resources of processing unit 104 such that each of processing portions 106 and 108 is assigned to a different VM and thus spatially partitioned among the VMs. To support this spatial partitioning, processor 102 assigns a VM's VF to the corresponding processing portion, and the VM interacts with the corresponding processing portion using its assigned VF. Thus, in the example of FIG. 1, processor 102 assigns VM 110 to processing portion 106 and assigns VF 111 to VM 110. VM 110 thus interacts with processing portion 106 using VF 111, in particular to send graphics operations to processing portion 106 and to receive any response data or control information. Similarly, processor 102 assigns VM 112 to processing portion 108 and assigns VF 113 to VM 112. Thus, the VM 112 interacts with the processing portion 108 using the VF 113 .

[0020] Because the processing portions 106 and 108 are spatially partitioned relative to the VMs 110 and 112, each processing portion can be reset without affecting operation in the other portions. Thus, each of the VFs 111 and 113 is configured to send a reset request directly to the processing portions 106 and 108, respectively, in response to detecting one or more specified reset conditions. That is, in sending the reset request, the VFs 111 and 113 bypass the host device driver 116 and the hypervisor 117, and thus omit sending an interrupt or other communication to the host device driver 116 or the hypervisor 117 to indicate the requested reset, and the VFs 111 and 113 do not rely on the host device driver 116 or the hypervisor 117 to trigger or control the requested reset. Because the host device driver 116 and the hypervisor 117 are bypassed, overhead associated with the reset process is reduced and isolation between the VMs 110 and 112 is enhanced. This increased isolation also improves security between VF111 and VF113, since a malicious VM cannot employ a reset request to affect the performance of another VM, for example.

[0021] To illustrate the reset sequence, in some embodiments, the VF 111 detects a stall in the processing portion 106, for example because the processing portion 106 did not send an expected message or response to the local device driver 118 within a specified time. In response to detecting that the processing portion 106 has stalled, the local device driver 118 prepares the VM 110 for a device reset and, upon completion of the preparation (e.g., by notifying any software in the VM 110 of the reset), sends a message indicating to the VF 111 to proceed with the reset. In response to the message, the local device driver 118 sends a reset request to the local SMU 122, which in response to the reset request executes a specified reset sequence on the processing portion 106. When the reset sequence is complete, the local SMU 122 sends a completion message to the local device driver 118. In response to the completion message, the local device driver notifies the OS running in the VM 110 that the reset is complete. Thus, the VF 111 handles the reset of the processing portion directly, bypassing the host device driver 116 and the hypervisor 117.

[0022] 2 is a block diagram of an example of directly resetting the processing portion 106 of the processing unit 104, according to some embodiments. In the illustrated example, the processing portion 106 is in a stalled state, in other words, the processing portion 106 is hung. In response to detecting the stalled state, the local device driver 118 attempts to reset the processing portion 106. Accordingly, the local device driver 118 performs a handshake 220 with the local SMU 122. For example, during the handshake 220, the local device driver 118 informs the SMU 122 that the processing portion 106 needs to be reset. In response, the SMU 122 prepares the processing portion 106 for reset.

[0023] Once ready (e.g., by signaling a reset to any hardware in the processing portion 106), the local SMU 122 sends a reset request 221 directly to the processing portion 106, bypassing the host device driver 116. In response to the reset request 221, the processing portion 106 executes a reset sequence indicated by the reset request 221. The reset sequence clears the stall condition in the processing portion 106, so that the processing portion 106 is no longer hung and prepares the processing portion 106 to perform further operations. After the reset is complete, the local SMU 122 sends a message back to the local device driver 118 to indicate completion of the reset. This completes the handshake 220. Thus, in the example of FIG. 2, the processing portion 106 is reset directly by the local SMU 122. That is, the local SMU 122 does not employ virtualized resources of the processor 102, such as the host device driver 116 or the hypervisor 117, as an intermediary to perform a reset of the processing portion 106, and bypasses the host device driver 116 and the hypervisor 117, thus reducing the overhead associated with the reset process and improving overall processing efficiency in the processing system 100.

[0024] As mentioned above, in some embodiments, processing unit 104 is a GPU, and processing portions 106 and 108 implement different rendering engines. An example according to some embodiments is shown in Figure 3. In particular, Figure 3 shows a GPU 304 that corresponds to processing unit 104 of Figure 1. GPU 304 includes GPU chiplets 306 and 308 that correspond to processing portions 106 and 108, respectively.

[0025] In some embodiments, the GPU 304 is formed as a multi-chip module (e.g., a semiconductor die package) that includes two or more base integrated circuit dies communicatively coupled together with a bridge chip(s) such that the GPU 304 is usable (e.g., addressable) like a single semiconductor integrated circuit. Those skilled in the art will recognize that conventional (e.g., non-multi-chip) semiconductor integrated circuits are manufactured as dies (e.g., single-chip ICs) that are formed as or within a wafer and later separated from the wafer (e.g., when the wafer is diced), and often multiple ICs are manufactured simultaneously within a wafer. The ICs and possibly discrete circuits, as well as possibly other components (such as non-semiconductor packaging substrates including printed circuit boards, interposers, and possibly others), are assembled into a multi-die processor.

[0026] In various embodiments, the GPU 304 includes one or more base IC dies employing processing stacked die chiplets according to some embodiments. The base die is formed as a single semiconductor chip package including N communicatively coupled stacked die chiplets. For example, in the illustrated embodiment, the GPU 304 includes two chiplets, designated chiplets 306 and 308. Although the various embodiments are described below in the specific context of a GPU chiplet for ease of illustration and explanation, it should be appreciated that the concepts described herein are equally applicable to other processors, including accelerated processing units (APUs), discrete GPUs (dGPUs), artificial intelligence (AI) accelerators, other parallel processors, and the like. Furthermore, in some embodiments, the GPU 304 is integrated into the same semiconductor chip package as the processor 102 such that the processing system 100 is integrated into a single semiconductor chip package.

[0027] In various embodiments, the term "chiplet" as used herein refers to any device that includes, but is not limited to, the following characteristics: 1) the chiplet includes active silicon dies that include at least a portion of the computational logic used to solve a complete problem (i.e., the computational workload is distributed across multiple of these active silicon dies); 2) the chiplets are packaged together as a monolithic unit on the same substrate; and 3) the programming model used to control a particular set of chiplets maintains the notion that the combination of these individual computational dies (e.g., a set of graphics processing stacked die chiplets) is a single monolithic unit. That is, each chiplet of a particular set is not exposed as an individual device to an application that uses the set of chiplets to process a computational workload, but instead, the set of chiplets is exposed to the application such that it collectively appears as an integrated processing unit, such as a graphics processing unit (GPU) or central processing unit (CPU). In various embodiments, the GPU 304 includes an inter-chip data fabric (not shown) that acts as a high-bandwidth die-to-die interconnect between the chiplets. Additionally, in various embodiments, each of the chiplets 306 and 308 includes one or more levels of cache memory and one or more memory PHYs (not shown) for communicating with external system memory modules, such as dynamic random access memory (DRAM) modules.

[0028] Each of the chiplets 306 and 308 implements a different rendering engine, denoted as rendering engine 325 and 324, respectively. Each of the rendering engines 324 and 325 is configured to execute received graphics commands (e.g., draw commands 322). Furthermore, each of the rendering engines 324 and 325 is configured to operate independently or substantially independently from the other rendering engine, and each of the rendering engines 324 and 325 can execute a reset sequence that does not affect the operation in the other rendering engine. This allows each of the rendering engines 324 and 325 to be assigned to a different VF and to execute graphics commands on behalf of the corresponding VM. Thus, the rendering engines 324 and 325 are spatially separated with respect to the VMs 110 and 112, and thus can be operated and reset independently by the VMSs 110 and 112.

[0029] For purposes of illustration, in the example of Figure 3, VF 111 is assigned to rendering engine 324 and VF 113 is assigned to rendering engine 325. In response to a stall in rendering engine 324, VF 111 directly resets rendering engine 324 in a manner similar to that described with respect to Figure 2. In particular, in response to detecting a stall in rendering engine 324, local device driver 118 performs a handshake 220 with local SMU 122 and, upon completion of handshake 220, sends a reset request 221 to rendering engine 324. In response to reset request 221, rendering engine 324 performs a specified reset sequence, thus clearing the stall condition and preparing rendering engine 324 to execute additional graphics commands.

[0030] At the same time that the VF 111 directly resets the rendering engine 324, the VF 113 sends the draw commands 322 generated by the VM 112 to the rendering engine 325. In response to the draw commands 322, the rendering engine 325 performs the set of operations indicated by the commands. In at least some embodiments, the rendering engine 325 executes these commands at the same time that the rendering engine 324 executes the reset sequence in response to the reset request 221. Thus, in the example of FIG. 3, the rendering engine 324 is reset independently of and at the same time as the rendering engine 325 executing the draw commands 322.

[0031] 4 illustrates a flow diagram of a method 400 of a virtual function to directly reset a processing portion of a processing unit, according to some embodiments. Method 400 is described with respect to an exemplary implementation in processing system 100 of FIG. However, it will be appreciated that in other embodiments, method 400 is performed in a processing system having a configuration different from that of processing system 100.

[0032] In block 402, the host device driver 116 assigns VFs 111 and 113 for VMs 110 and 112 to the processing portions 106 and 108, respectively. In block 404, the local device driver 118 detects an error in the processing portion 106, such as a notification that the processing portion 106 has stalled. In response, in block 406, the local device driver 118 performs a handshake 220 with the local SMU 122. In block 408, once the handshake 220 is complete, the local SMU 122 sends a reset request 221 to the processing portion 106, thus resetting the processing portion 106 directly, independent of the processing portion 108, and bypassing the device driver 116.

[0033] As disclosed herein, in some embodiments, a method includes detecting a reset condition in a virtual function of a virtual machine executing on a processing system, and in response to detecting the reset condition, a local system management unit (SMU) of the processing unit initiates a reset sequence for a processing portion of the processing unit associated with the virtual function, where the initiating bypasses a host driver of the processing system. In one aspect, the reset sequence includes a handshake between the local SMU and a device driver of the virtual machine. In another aspect, the initiating bypasses a host driver of the processing system. In yet another aspect, the processing unit includes multiple semiconductor dies and the portion of the processing unit includes any of the multiple dies.

[0034] In one aspect, the reset sequence includes a reset sequence for resetting any of the multiple dies independent of resetting other dies of the multiple dies. In another aspect, the processing unit is spatially divided into multiple processing portions. In yet another aspect, each of the multiple processing portions is assigned to a different virtual function of the multiple virtual functions.

[0035] In some embodiments, a non-transitory computer-readable medium tangibly embodies a set of instructions for operating a processor, the instructions including: in response to detecting a reset condition in a virtual function of a virtual machine, initiating a reset sequence for a processing portion of the processing unit; and in response to initiating the reset sequence, performing a handshake between a local system management unit (SMU) of the processing unit and a local device driver of the virtual machine. In one aspect, the reset sequence omits a handshake between the virtual function and a host driver of the processing system. In another aspect, the processing unit includes a graphics processing unit (GPU). In yet another aspect, the GPU includes multiple GPU chiplets, and the processing portion corresponds to any of the multiple GPU chiplets.

[0036] In one aspect, the processing portion includes a rendering engine assigned to a virtual machine, hi another aspect, the reset condition includes an error detected in the processing portion of the processing unit.

[0037] In some embodiments, a processing system includes a processing unit and a processor executing a virtual machine and a virtual function associated with the virtual machine, where in response to detecting a reset condition, a local system management unit (SMU) of the processing unit initiates a reset sequence for a processing portion of the processing unit associated with the virtual function, where the reset sequence bypasses a host driver of the processing system. In one aspect, the reset sequence includes a handshake between the local SMU and a device driver of the virtual machine. In another aspect, the reset sequence bypasses a hypervisor of the processing system.

[0038] In one aspect, the processing unit includes multiple semiconductor dies and the portions of the processing unit include any of the multiple dies. In another aspect, the reset sequence includes a reset sequence for resetting any of the multiple dies independently of other dies of the multiple dies. In yet another aspect, the processing unit is spatially divided into multiple processing portions. In one aspect, each of the multiple processing portions is assigned to a different virtual function of the multiple virtual functions.

[0039] In some embodiments, certain aspects of the techniques described above are implemented by one or more processors of a processing system executing software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied in a non-transitory computer-readable storage medium. The software may include instructions and specific data that, when executed by the one or more processors, operate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer-readable storage medium may include, for example, a magnetic or optical disk storage device, a solid-state storage device such as a flash memory, a cache, a random access memory (RAM), or other non-volatile memory device(s), etc. The executable instructions stored in the non-transitory computer-readable storage medium may be implemented as source code, assembly language code, object code, or other form of instructions that can be interpreted or otherwise executed by one or more processors.

[0040] In addition to the above, it should be noted that not all activities or elements described in the summary description are required, some of the specific activities or devices may not be required, one or more additional activities may be performed, and one or more additional elements may be included. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, those skilled in the art will appreciate that various changes and modifications can be made without departing from the scope of the invention as set forth in the claims. Thus, the specification and drawings should be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the invention.

[0041] Benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, the benefits, advantages, solutions to problems, and features by which any benefit, advantage, or solution may occur or be manifested are not to be construed as critical, essential, or essential features of any or all claims. Moreover, the specific embodiments described above are illustrative only, as the disclosed invention may be modified and practiced in different but similar manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as set forth in the appended claims. It is therefore apparent that the specific embodiments described above may be altered or modified, and all such variations are considered to be within the scope of the disclosed invention. Accordingly, the protection sought herein is set forth in the appended claims.

Claims

1. 1. A method comprising: Detecting a reset condition in a virtual function of a virtual machine executing on a processing system; in response to detecting the reset condition, a local system management unit (SMU) of a processing unit initiates a reset sequence for a processing portion of the processing unit associated with the virtual function, wherein the initiating bypasses a host driver of the processing system. method.

2. the reset sequence includes a handshake between the local SMU and a device driver of the virtual machine; 10. The method of claim 1.

3. the initiating bypasses a hypervisor of the processing system.

10. The method of claim 1.

4. the processing unit includes a plurality of semiconductor dies, and the processing portion of the processing unit includes any one of the plurality of semiconductor dies; 10. The method of claim 1.

5. the reset sequence includes a reset sequence for resetting the any one of the plurality of semiconductor dies independently of resetting other semiconductor dies of the plurality of semiconductor dies.

10. The method of claim 1.

6. The processing unit is spatially divided into a plurality of processing portions including the processing portion.

10. The method of claim 1.

7. each of the plurality of processing units is assigned to a different virtual function among a plurality of virtual functions including the virtual function; The method of claim 6.

8. 1. A processing system comprising: a processing unit; a processor that executes a virtual machine and a virtual function associated with the virtual machine, wherein in response to detecting a reset condition, a local system management unit (SMU) of the processing unit initiates a reset sequence for a processing portion of the processing unit associated with the virtual function; the reset sequence bypasses a host driver of the processing system; Processing system.

9. the reset sequence includes a handshake between the local SMU and a device driver of the virtual machine; The processing system of claim 8.

10. the reset sequence bypassing a hypervisor of the processing system. The processing system of claim 9.

11. the processing unit includes a plurality of semiconductor dies, and the processing portion of the processing unit includes any one of the plurality of semiconductor dies; The processing system of claim 8.

12. the reset sequence includes a reset sequence for resetting the any one of the plurality of semiconductor dies independently of other semiconductor dies of the plurality of semiconductor dies; The processing system of claim 8.

13. the processing unit is spatially divided into a plurality of processing portions; The processing system of claim 8.

14. each of the plurality of processing portions is assigned to a different virtual function among a plurality of virtual functions; The processing system of claim 13.

Images