Reset processing unit by virtual function

Abstract

A virtual function (VF) (111) of a virtual machine (110) can directly reset the processing portion (106) of a processing unit (104). The VF directly initiates the reset of the processing portion, and the host driver (116) associated with the processing unit is bypassed during the reset process. By allowing the direct reset of the processing portion, the processing system (100) reduces the overhead associated with the reset process, improves system security, and improves the isolation of the entire VM and hardware in the processing system.

Description

Background Technology

[0001] To support the efficient use of processing resources, some processing systems support virtualization, where multiple independent processing environments, referred to as virtual machines (VMs), utilize the processing resources of the processing systems. In some cases, the processing system utilizes one or more virtualization layers that abstract the processing system's hardware resources, enabling 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 processing system's hardware resources and the running VMs. The hypervisor utilizes host device drivers that interface with the hardware resources and translates communications between the VM's local device drivers and the host drivers. Thus, the hypervisor enables the processing system's hardware resources to appear to the VM as dedicated local hardware resources, thereby allowing the VM 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 hardware resources causes processing inefficiencies. Brief explanation of the drawing

[0002] The present disclosure may be better understood by those skilled in the art by referring to the accompanying drawings, and many features and advantages may become apparent. The use of the same reference symbols in different drawings indicates similar or identical items. FIG. 1 is a block diagram of a processing system that supports direct reset of a processing portion of a processing unit by a virtual function according to some embodiments. FIG. 2 is a block diagram of a virtual function of the processing system of FIG. 1 that directly resets the processing portion of the processing unit according to some embodiments. FIG. 3 is a block diagram illustrating an example of a virtual function that resets a rendering engine in a graphics processing unit chiplet according to some embodiments. FIG. 4 is a flowchart of a method of a virtual function that directly resets a processing portion of a processing unit according to some embodiments. Specific details for implementing the invention

[0003] FIGS. 1 through 4 illustrate techniques for enabling a virtual function (VF) of a virtual machine to directly reset a processing portion of a processing unit. The VF directly initiates the reset of the processing portion, and the host driver associated with the processing unit is bypassed during the reset process. By allowing the direct reset of the processing portion, the processing system reduces the overhead associated with the reset process, enhances system security, and improves the isolation of the entire VM and hardware in the processing system.

[0004] For example, in some cases, a processing system supports the virtualization of hardware resources through the partitioning of hardware resources, such as graphics processing units (GPUs). A physical function (PF) that manages operations on the hardware resource is assigned to the hardware resource. A different VF is assigned to each VM running in the processing system, and the PFs and other virtualization entities in the processing system manage the provisioning of hardware resources for the VMs through the individual VFs. That is, the VF provides a method for the corresponding VM to interface with the PF and control the portion of hardware resources allocated to the VM.

[0005] In some conventional processing systems, hardware resources are temporally partitioned among different VFs. Thus, each VF is allocated a portion of a given time unit, also referred to as a "slot," and each VF is allowed to control the hardware resource during its allocated time slots. In some situations, when performing operations on behalf of a VF, an error will occur in the hardware resource for a specific VF, such as hardware resource stalling (or "hanging"). In response to these errors, the VF typically attempts to reset the hardware resource. However, in many cases, this reset affects operations executed by the hardware resource on behalf of other VFs. Therefore, for temporally partitioned hardware resources, the VF must work with the host driver to reset the hardware resource. Specifically, the guest driver interfacing with the VF must send an interrupt to the host driver to request a reset, and the host driver identifies which VF sent the request and which temporal partition is associated with that VF. Then, the host driver communicates with the A hypervisor or firmware of the host device's system management unit (SMU) to reset hardware resources (this communication process is referred to as a "handshake" between the host driver and the SMU firmware). During the reset, other VFs will not be able to 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.

[0006] In contrast to temporally partitioned hardware resources, in some embodiments, hardware resources are spatially partitioned so that different processing parts of the hardware resources are assigned to different VFs (and accordingly different corresponding VMs). For example, in some embodiments, the GPU includes multiple rendering engines, each rendering engine being implemented by different and independent hardware, such as different GPU chiplets. When hardware resources are spatially partitioned, in at least some cases, resetting one processing part of the resource does not affect operations in other processing parts. Therefore, using the techniques of this specification, a VF controlling a portion of a spatially partitioned hardware resource can directly reset its assigned processing part, thereby bypassing the host driver and simplifying the reset process.

[0007] Furthermore, security in the processing system is enhanced because the host device driver is bypassed. To illustrate, in a typical system where all reset requests by a VF are sent to the host driver, a malicious driver or application may send multiple reset requests. Service to these multiple requests consumes the bandwidth of the corresponding hardware resources and affects the quality of service for all VMs running in the processing system. By using the techniques described herein, the VF resets its associated portion of the hardware resources and bypasses the host driver. Therefore, issuing multiple reset requests by the VF affects only the VM associated with that VF and does not affect the quality of service for other VMs.

[0008] FIG. 1 illustrates a block diagram of a processing system (100) configured to support a direct reset of the processing portion of a processing unit by a virtual function, according to some embodiments. The example of FIG. 1 is discussed in relation to some exemplary embodiments where the processing is a GPU. However, in other embodiments, it will be understood that the techniques described herein may be applied to other types of processing units, such as vector processing units, parallel processing units, machine learning processing units, artificial intelligence processing units, etc.

[0009] The processing system (100) is configured to execute sets of instructions such as virtual machines (VMs), operating systems, and applications. By doing so, the processing system performs specific tasks indicated by the sets of instructions on behalf of an electronic device. Accordingly, in different embodiments, the processing system (100) is integrated into one of various electronic devices such as a server, a desktop computer, a laptop computer, a game console, a tablet, a smartphone, etc. To support the execution of sets 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 exemplified 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 integrated 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 integrated into a multi-chip integrated circuit.

[0010] The processor (102) is a general-purpose processor and is configured to execute a set of general-purpose instructions. Accordingly, in some embodiments, the processor (102) is a central processing unit (CPU) having one or more processor cores (not shown) each comprising one or more instruction pipelines configured to execute program threads representing parts of a set of instructions in a pipelined manner. While executing the program threads, the instruction pipelines generate graphic commands (e.g., drawing commands) representing requests for specific graphic operations.

[0011] The processing unit (104) is configured to receive commands for executing specific class or type operations and is further configured to execute corresponding operations indicated by the commands. For example, in some embodiments, the processing unit (104) is a GPU configured to execute drawing operations, texture operations, shader operations, tessellation operations, vector processing operations, etc. The processing unit (104) includes a plurality of processing parts, including a processing part (106) and a processing part (108). In some embodiments, the processing unit (104) includes additional processing parts not illustrated in FIG. 1. As used herein, a processing part of the processing unit is a set of circuits that collectively execute processing operations independently or substantially independently of other processing parts. For example, in some embodiments, the processing unit (104) is a GPU, and each of the processing parts (106 and 108) implements a rendering engine, wherein each rendering engine operates substantially independently of the other rendering engine to execute graphics operations based on the received commands.

[0012] The processing unit (104) also includes one or more local system management units (SMUs), such as an SMU (122). The SMU (122) is a hardware module, a software module, or a combination thereof configured to manage some operations of the processing unit (104) overall, particularly some operations including reset operations of the processing parts (106 and 108). In some embodiments, when the processing unit (104) has a plurality of SMUs (122), each SMU (122) controls one processing part (106 or 108).

[0013] In the example of FIG. 1, the processing system (100) implements a virtualized computing environment, wherein virtual machines (e.g., VMs (110, 112)) are executed on a processor, and the processing system (100) exposes the physical resources of the system to different VMs as if the physical resources were dedicated physical devices accessed by the VMs. For example, in some embodiments, the processor (102) is configured to virtualize the processing unit (104) overall, so that the physical resources of the processing unit (104) are used simultaneously by multiple VMs, but the physical resources appear to each of the multiple VMs as a physical processing unit dedicated to that VM. Additionally, in at least some embodiments, the processor (102) implements virtualization by spatially partitioning the hardware resources of the processing unit (104). Specifically, the processing unit assigns processing parts (106 and 108) to different virtual machines so that each VM uses the hardware resources of the assigned processing part independently of the other VMs.

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

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

[0016] A host device driver (116) is a device driver running on the processor (102) to provide an interface between the processing unit (104) and the modules (hardware or software) of the processor (102). Accordingly, in at least some embodiments, the host device driver (116) is generally configured to receive communications (e.g., requests for specific operations) from the modules of the processor (102), such as from the VM (110) to the local device driver (118). The host device driver (116) manages the provisioning of these communications to the processing unit (104), including converting these communications into a specific format expected by the processing unit (104), ensuring that the communications satisfy any timing or other communication requirements of the processing unit (104), etc. The host device driver (116) also manages communications received from the processing unit (104) in response to communications from the host device driver (116), including converting the received communications into formats expected by the modules of the processor (102).

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

[0018] Each VM uses a corresponding VF to access the hardware resources of the processing unit (104). In particular, as mentioned above, the processing system (100) virtualizes the hardware resources of the processing unit (104) so ​​that each of the processing parts (106 and 108) is assigned to different VMs and is spatially partitioned among the VMs accordingly. To support this spatial partitioning, the processor (102) assigns a VF for a VM to a corresponding processing part, and the VM uses the assigned VF to interact with the corresponding processing part. Thus, in the example of FIG. 1, the processor (102) assigns a VM (110) to a processing part (106) and also assigns a VF (111) to the VM (110). Thus, the VM (110) uses the VF (111) to interact with the processing part (106), in particular to transmit graphic operations to the processing part (106) and to receive any response data or control information. Similarly, the processor (102) assigns the VM (112) to the processing part (108) and also assigns the VF (113) to the VM (112). Thus, the VM (112) uses the VF (113) to interact with the processing part (108).

[0019] Because the processing parts (106 and 108) are spatially partitioned with respect to the VMs (110 and 112), each processing part can be reset without affecting operations in other parts. Accordingly, each of the VFs (111 and 113) is configured to directly send reset requests to each of the processing parts (106 and 108) in response to detecting one or more specified reset conditions. That is, when sending reset requests, the VFs (111 and 113) bypass the host device driver (116) and the hypervisor (117), thus omitting the sending of any interrupts or other transmissions 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, the overhead associated with the reset process is reduced, and the isolation between the VMs (110 and 112) is improved. This increased isolation also improves security between the VFs (111 and 113) because, for example, a malicious VM cannot use reset requests to affect the performance of other VMs.

[0020] To illustrate the reset sequence, in some embodiments, the VF (111) detects a stall in the processing part (106) because, for example, the processing part (106) has not sent an expected message or response to the local device driver (118) within a specified amount of time. In response to the detection that the processing part (106) has stalled, the local device driver (118) prepares the VM (110) for a device reset and, upon completion of preparation, sends a message to the VF (111) indicating that the reset will proceed (for example, by notifying any software in the VM (110) of the reset). In response to the message, the local device driver (118) sends a reset request to the local SMU (122), and the local SMU executes a specified reset sequence for the processing part (106) in response to the reset request. Upon completion of the reset sequence, 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 on the VM (110) that the reset is complete. Thus, the VF (111) directly handles the reset of the processing part and bypasses the host device driver (116) and the hypervisor (117).

[0021] FIG. 2 is a block diagram of an example of directly resetting a processing portion (106) of a processing unit (104) according to some embodiments. In the example illustrated, the processing portion (106) is in a stall state, or, that is to say, the processing portion (106) is hanging. In response to detecting the stall state, the local device driver (118) intends 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) notifies the SMU (122) that the processing portion (106) needs to be reset. In response, the SMU (122) prepares the processing portion (106) for reset.

[0022] When preparation is complete (e.g., by notifying any hardware in the processing section (106) of the reset), the local SMU (122) bypasses the host device driver (116) by sending a reset request (221) directly to the processing section (106). In response to the reset request (221), the processing section (106) executes the reset sequence indicated by the reset request (221). The reset sequence clears the stall state in the processing section (106) so that the processing section (106) is no longer hanging and prepares the processing section (106) to perform additional operations. After the reset is complete, the local SMU (122) sends a message back to the local device driver (118) to indicate the completion of the reset. Thus, the handshake (220) is terminated. Thus, in the example of FIG. 2, the processing section (106) is reset directly by the local SMU (122). That is, the local SMU (122) does not use virtualization resources of the processor (102), such as the host device driver (116) or hypervisor (117), as intermediaries for performing a reset of the processing part (106), and bypasses the host device driver (116) and hypervisor (117) to reduce the overhead associated with the reset process and improve the overall processing efficiency in the processing system (100).

[0023] As mentioned above, in some embodiments, the processing unit (104) is a GPU, and the processing parts (106 and 108) implement different rendering engines. An example according to some embodiments is illustrated in FIG. 3. Specifically, FIG. 3 illustrates a GPU (304) corresponding to the processing unit (104) of FIG. 1. The GPU (304) includes GPU chiplets (306 and 308) corresponding to the processing parts (106 and 108), respectively.

[0024] In some embodiments, the GPU (304) is formed as a multi-chip module (e.g., semiconductor die package) comprising two or more base integrated circuit dies that are coupled together to communicate via bridge chip(s) so that the GPU (304) can be used as a single semiconductor integrated circuit (e.g., addressable). Those skilled in the art will recognize that conventional (e.g., non-multi-chip) semiconductor integrated circuits are manufactured as wafers or as dies (e.g., single-chip ICs) formed on wafers and later separated from wafers (e.g., when wafers are diced); and that multiple ICs are often manufactured simultaneously on wafers. ICs and possibly individual circuits and possibly other components (e.g., non-semiconductor packaging substrates including printed circuit boards, interposers, and possibly others) are assembled in a multi-die processor.

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

[0026] In various embodiments, and as used herein, the term “chiplet” refers to any device comprising, but not limited to, the following characteristics: 1) the chiplet comprises an active silicon die containing at least a portion of the computational logic used to solve the entire problem (i.e., the computational workload is distributed across multiples 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 specific set of chiplets maintains the concept that the combination of these separate computational dies (e.g., a set of graphics processing stacked die chiplets) is a single monolithic unit. That is, each chiplet of a specific set is not exposed as a separate device to an application using the set of chiplets to process a computational workload; instead, the set of chiplets is exposed to the application to appear collectively as an integrated processing unit, such as a graphics processing unit (GPU) or a central processing unit (CPU). In various embodiments, the GPU (304) includes an inter-chip data fabric (not shown) that operates as a high-bandwidth die-to-die interconnect between 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.

[0027] Each of the chiplets (306 and 308) implements a different rendering engine designated as the rendering engines (325 and 324). Each of the rendering engines (324 and 325) is configured to execute received graphics commands (e.g., drawing commands (322)). Additionally, each of the rendering engines (324 and 325) is configured to operate independently or substantially independently of other rendering engines, and each of the rendering engines (324 and 325) can execute a reset sequence that does not affect operations in other rendering engines. This enables each of the rendering engines (324 and 325) to be assigned to a different VF and execute graphics commands on behalf of the corresponding VM. Thus, the rendering engines (324 and 325) are spatially partitioned with respect to the VMs (110 and 112), and accordingly can be operated and reset independently by the VMs (110 and 112).

[0028] For example, in the example of FIG. 3, VF (111) is assigned to the rendering engine (324), and VF (113) is assigned to the rendering engine (325). In response to a stall in the rendering engine (324), VF (111) directly resets the rendering engine (324) in a manner similar to that described in relation to FIG. 2. Specifically, in response to detecting a stall in the rendering engine (324), the local device driver (118) performs a handshake (220) with the local SMU (122) and, upon completion of the handshake (220), sends a reset request (221) to the rendering engine (324). In response to the reset request (221), the rendering engine (324) executes a specified reset sequence to clear the stall state and prepares the rendering engine (324) to execute additional graphics commands.

[0029] At the same time that VF (111) directly resets the rendering engine (324), VF (113) transmits a drawing command (322) generated by VM (112) to the rendering engine (325). In response to the drawing command (322), the rendering engine (325) executes a set of actions indicated by the command. In at least some embodiments, the rendering engine (325) executes these commands at the same time that the rendering engine (324) executes a reset sequence in response to a reset request (221). Thus, in the example of FIG. 3, the rendering engine (324) is reset independently and simultaneously with the rendering engine (325) executing the drawing command (322).

[0030] FIG. 4 illustrates a flowchart of a method (400) of a virtual function that directly resets a processing portion of a processing unit according to some embodiments. The method (400) is described in relation to an exemplary embodiment of the processing system (100) of FIG. 1. However, it will be understood that in other embodiments, the method (400) may be implemented in processing systems having configurations different from the configuration of the processing system (100).

[0031] In block (402), the host device driver (116) assigns VFs (111 and 113) for VMs (110 and 112) to the processing parts (106 and 108), respectively. In block (404), the local device driver (118) detects an error in the processing part (106), such as an indication that the processing part (106) has stalled. In response to this, in block (406), the local device driver (118) performs a handshake (220) with the local SMU (122). In block (408), upon completion of the handshake (220), the local SMU (122) sends a reset request (221) to the processing part (106) to directly reset the processing part (106) independently of the processing part (108) and bypass the device driver (116).

[0032] As disclosed herein, in some embodiments, the method comprises: detecting a reset condition in a virtual function of a virtual machine running in a processing system; and in response to detecting the reset condition, the local system management unit (SMU) of the processing unit initiating a reset sequence for a processing portion of the processing unit associated with the virtual function—the initiating step bypasses the host driver of the processing system. In one embodiment, the reset sequence includes a handshake between the device driver of the virtual machine and the local SMU. In another embodiment, the initiating step bypasses the host driver of the processing system. In yet another embodiment, the processing unit comprises a plurality of semiconductor dies, and a portion of the processing unit comprises one of the plurality of dies.

[0033] In one embodiment, the reset sequence includes a reset sequence for resetting one of the plurality of dies independently of resetting the other dies among the plurality of dies. In another embodiment, the processing unit is spatially partitioned into a plurality of processing parts. In yet another embodiment, a different virtual function among a plurality of virtual functions is assigned to each of the plurality of processing parts.

[0034] In some embodiments, a non-transient computer-readable medium tangibly embodies a set of instructions for manipulating a processor, the instructions include: an instruction for initiating a reset sequence for a processing portion of a processing unit in response to detecting a reset condition in a virtual function of a virtual machine; and an instruction for executing a handshake between a local device driver of a virtual machine and a local system management unit (SMU) of a processing unit in response to initiating the reset sequence. In one embodiment, the reset sequence omits a handshake between a host driver of a processing system and a virtual function. In another embodiment, the processing unit includes a graphics processing unit (GPU). In yet another embodiment, the GPU includes a plurality of GPU chiplets, wherein the processing portion corresponds to one of the plurality of GPU chiplets.

[0035] In one embodiment, the processing part includes a rendering engine assigned to a virtual machine. In another embodiment, the reset condition includes an error detected in the processing part of the processing unit.

[0036] In some embodiments, the processing system comprises: a processing unit; a virtual machine and a processor for executing 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, and the reset sequence bypasses the host driver of the processing system. In one embodiment, the reset sequence includes a handshake between the device driver of the virtual machine and the local SMU. In another embodiment, the reset sequence bypasses the hypervisor of the processing system.

[0037] In one embodiment, the processing unit comprises a plurality of semiconductor dies, wherein a portion of the processing unit comprises one of the plurality of dies. In another embodiment, the reset sequence comprises a reset sequence for resetting one of the plurality of dies independently of the other dies among the plurality of dies. In yet another embodiment, the processing unit is spatially partitioned into a plurality of processing portions. In one embodiment, a different virtual function among a plurality of virtual functions is assigned to each of the plurality of processing portions.

[0038] In some embodiments, specific aspects of the aforementioned technologies may be implemented by one or more processors of a processing system executing software. The software comprises one or more executable instruction sets stored on a non-transient computer-readable storage medium or otherwise tangibly implemented. When executed by one or more processors, the software may include instructions and specific data that manipulate one or more processors to perform one or more aspects of the technologies described above. The non-transient computer-readable storage medium may include, for example, magnetic or optical disk storage devices, solid-state storage devices such as flash memory, caches, random access memory (RAM), or other non-volatile memory devices or devices. The executable instructions stored on the non-transient computer-readable storage medium may be in source code, assembly language code, object code, or other instruction formats that are interpreted or otherwise executable by one or more processors.

[0039] It should be noted that not all activities or elements described above are required in the general description, and that specific activities or parts of a device may not be required, and that one or more additional activities may be performed or elements may be included in addition to those described above. Furthermore, the order in which activities are listed does not necessarily correspond to the order in which they are performed. Additionally, concepts have been described with reference to specific embodiments. However, those skilled in the art will understand that various modifications and changes are possible without departing from the scope of the disclosure, as described in the claims below. Accordingly, this specification and drawings should be considered illustrative rather than restrictive, and all such modifications are intended to be included within the scope of the disclosure.

[0040] Benefits, other advantages, and solutions to problems have been described above in relation to specific embodiments. However, any benefit, benefit, solution to problems, and any feature(s) that may give rise to or make more apparent any benefit, benefit, or solution should not be interpreted as an important, required, or essential feature of any or all claims. Furthermore, the specific embodiments disclosed above are merely illustrative, and the subject matter disclosed may be modified and practiced in different but equivalent ways that are obvious to those skilled in the art having the benefit of the teachings of this specification. No limitation is intended on the details of the configuration or design described in this specification other than those set forth in the following claims. Accordingly, it is evident that the specific embodiments disclosed above may be altered or modified, and that all such variations are considered within the scope of the subject matter disclosed. Accordingly, the scope of protection sought in this specification is as set forth in the claims below.

Claims

Claim 1 A method comprising: detecting a reset condition in a virtual function of a virtual machine running in a processing system; and in response to detecting the reset condition, a local system management unit (SMU) of a processing unit initiating a reset sequence for a processing portion of the processing unit associated with the virtual function, wherein the initiating step bypasses a host driver of the processing system. Claim 2 A method according to claim 1, wherein the reset sequence includes a handshake between the device driver of the virtual machine and the local SMU. Claim 3 In claim 1, the disclosed step is a method of bypassing the hypervisor of the processing system. Claim 4 A method according to claim 1, wherein the processing unit comprises a plurality of semiconductor dies, and the processing portion of the processing unit comprises one of the plurality of semiconductor dies. Claim 5 A method according to claim 4, wherein the reset sequence comprises a reset sequence for resetting one semiconductor die among the plurality of semiconductor dies independently of resetting other semiconductor dies among the plurality of semiconductor dies. Claim 6 A method according to claim 1, wherein the processing unit is spatially partitioned into a plurality of processing parts including the processing part. Claim 7 A method according to claim 6, wherein each of the plurality of processing parts is assigned a different virtual function among a plurality of virtual functions including the virtual function. Claim 8 A processing system comprising: a processing unit; and a processor for executing a virtual machine and a virtual function associated with said virtual machine, wherein, in response to detecting a reset condition, a local system management unit (SMU) of said processing unit initiates a reset sequence for a processing portion of said processing unit associated with said virtual function, and said reset sequence bypasses a host driver of said processing system. Claim 9 In claim 8, the processing system wherein the reset sequence includes a handshake between the device driver of the virtual machine and the local SMU. Claim 10 In claim 9, the above reset sequence is a processing system that bypasses the hypervisor of the processing system. Claim 11 A processing system according to claim 8, wherein the processing unit comprises a plurality of semiconductor dies, and the processing portion of the processing unit comprises one of the plurality of semiconductor dies. Claim 12 A processing system according to claim 11, wherein the reset sequence comprises a reset sequence for resetting one semiconductor die among the plurality of semiconductor dies independently of other semiconductor dies among the plurality of semiconductor dies. Claim 13 In paragraph 8, the processing unit is a processing system spatially partitioned into a plurality of processing parts. Claim 14 A processing system according to claim 13, wherein each of the plurality of processing parts is assigned a different virtual function among the plurality of virtual functions. Claim 15 delete Claim 16 delete Claim 17 delete Claim 18 delete Claim 19 delete Claim 20 delete

Images