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 Art

[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, enabling the VM to use device drivers, application program interfaces (APIs), operating systems, and other software designed and implemented for a non-virtualized environment. 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 converts communications between the local device drivers of the VMs and the host drivers. Thus, the hypervisor enables the hardware resources of the processing system to appear to the VM as dedicated local hardware resources, and enables the VM to use standard device drivers and other software designed to be used 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 by reference to the accompanying drawings, and its numerous features and advantages may become apparent to those skilled in the art. The use of the same reference numerals in different drawings indicates similar or identical items.

Brief Description of the Drawings

[0003] [Figure 1] 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. [Figure 2]This is a block diagram of the virtual functions of the processing system in Figure 1, which directly resets the processing portion of the processing unit according to several embodiments. [Figure 3] This block diagram shows an example of a virtual function for resetting the rendering engine in a graphics processing unit chiplet, according to several embodiments. [Figure 4] This is a flowchart illustrating a method for a virtual function that directly resets the processing portion of a processing unit, according to several embodiments. [Modes for carrying out the invention]

[0004] Figures 1-4 illustrate a technique that allows a virtual function (VF) of a virtual machine to directly reset the 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 enabling a direct reset of the processing portion, the processing system reduces the overhead associated with the reset process, enhances system security, and improves overall VM and hardware isolation in the processing system.

[0005] For illustrative purposes, in some cases, a processing system supports the virtualization of hardware resources through the partitioning of hardware resources such as graphics processing units (GPUs). Hardware resources are assigned physical functions (PFs) that manage the operation of those hardware resources. Each VM running in the processing system is assigned a different VF, and the PFs and other virtualization entities in the processing system manage the provision of hardware resources to the VMs through their respective VFs. In other words, a VF provides a way for the corresponding VM to interface with the PF and control the portion of the hardware resources allocated to the VM.

[0006] In some conventional processing systems, hardware resources are temporally divided among different VFs. Each VF is therefore allocated a portion, also called a "slot," of a predetermined time unit, during which each VF is allowed to control the hardware resource. In some situations, errors in a particular VF, such as a stall (or "hang") of the hardware resource when it performs an action on behalf of the VF, occur in the hardware resource. In response to such errors, the VF typically attempts to reset the hardware resource. However, such resets often affect actions performed by the hardware resource on behalf of other VFs. Therefore, for temporally divided hardware resources, the VF needs to work with the host driver to reset the hardware resource. Specifically, a guest driver interfacing with a VF needs to send an interrupt to the host driver to request a reset, and the host driver needs to identify which VF sent the request and which temporal division is associated with that VF. Next, the host driver communicates with the hypervisor or the 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, other VFs cannot run on the host device. After the hardware resource reset is complete, the host driver notifies the guest drivers associated with the VF that the reset is complete.

[0007] In contrast to temporally partitioned hardware resources, in some embodiments, hardware resources are spatially partitioned, resulting in different processing parts of the hardware resources being assigned to different VFs (and therefore to different corresponding VMs). For example, in some embodiments, a GPU includes multiple rendering engines, each rendering engine being implemented by different 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 the operation of other processing parts. Therefore, using the techniques herein, a VF controlling a portion of spatially partitioned hardware resources can directly reset its assigned processing part, 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. For example, in a conventional system where all reset requests from the VF are sent to the host driver, a malicious driver or application could send many reset requests. Service for these multiple requests consumes bandwidth on the corresponding hardware resources and therefore affects the quality of service of all VMs running in the processing system. Using the techniques described herein, the VF resets its allocated portion of the hardware resources and bypasses the host driver. Therefore, the issuance of multiple reset requests by the VF affects only the VM associated with that VF and does not affect the quality of service of other VMs.

[0009] Figure 1 is a block diagram of a processing system 100 configured to support direct reset of the processing portion of a processing unit by virtual functions, according to several embodiments. The examples in Figure 1 are described with respect to several exemplary embodiments in which the processing unit is a GPU. However, in other embodiments, it will be understood that the techniques described herein are applicable to other types of processing units such as vector processing units, parallel processing units, machine learning processing units, and artificial intelligence processing units.

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

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

[0012] The processing unit 104 is a processing unit configured to receive commands for performing 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, the processing unit 104 is a GPU configured to perform drawing operations, texture operations, shader operations, tessellation operations, vector processing operations, etc. The processing unit 104 includes a plurality of processing parts, including processing parts 106 and 108. In some embodiments, the processing unit 104 includes additional processing parts not shown in Figure 1. As used herein, a processing part of a processing unit is a set of circuits that collectively perform 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 processing parts 106 and 108 implements a rendering engine, and each rendering engine operates substantially independently of the others to perform graphics operations based on received commands.

[0013] Furthermore, the processing unit 104 includes one or more local system management units (SMUs), such as an SMU 122. The SMU 122 is generally a hardware module, a software module, or a combination thereof configured to manage several operations of the processing unit 104, particularly several operations including the reset operations of processing sections 106 and 108. In some embodiments, if the processing unit 104 has multiple SMUs 122, each SMU 122 controls one processing section 106 or 108.

[0014] In the example in Figure 1, the processing system 100 implements a virtualized computing environment, where virtual machines (e.g., VMs 110, 112) run on the processor, and the 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, the processor 102 is generally configured to virtualize the processing unit 104, so that the physical resources of the processing unit 104 are simultaneously utilized by multiple VMs, but the physical resources appear to each of the VMs as a dedicated physical processing unit for that VM. Furthermore, in at least some embodiments, the processor 102 implements virtualization by spatially partitioning the hardware resources of the processing unit 104. In particular, the processing unit assigns processing sections 106 and 108 to different virtual machines so that each VM utilizes the hardware resources of its processing section, which is allocated independently of other VMs.

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

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

[0017] The host device driver 116 is a device driver that runs on the processor 102 to provide an interface between the processor 102's modules (hardware or software) and the processing unit 104. Therefore, in at least some embodiments, the host device driver 116 is generally configured to receive communications (e.g., requests for specified actions) from the processor 102's modules, such as the VM110's local device driver 118. The host device driver 116 manages the provision of these communications to the processing unit 104, including ensuring that the communications satisfy the processing unit 104's timing or other communication requirements by converting them to a specific format expected by the processing unit 104. The host device driver 116 also manages communications received from the processing unit 104 in response to communications from the host device driver 116, which includes converting the received communications to a format expected by the processor 102's modules.

[0018] To further support the processing unit 104's access to hardware resources, processor 102 implements a set of VFs, including VF111 and VF113. Upon the start of VM execution, processor 102 assigns the VF corresponding to the VM so that each VF is uniquely assigned to a different VM. For example, in the example in Figure 1, VF111 is assigned to VM110 and VF113 is assigned to VM112.

[0019] Each VM uses its corresponding VF to access the hardware resources of the processing unit 104. In particular, as described above, the processing system 100 virtualizes the hardware resources of the processing unit 104 such that each of the processing sections 106 and 108 is assigned to a different VM, and thus spatially partitioned between the VMs. To support this spatial partitioning, the processor 102 assigns the VM's VF to the corresponding processing section, and the VM interacts with the corresponding processing section using its assigned VF. Thus, in the example in Figure 1, the processor 102 assigns VM 110 to processing section 106 and assigns VF 111 to VM 110. Therefore, VM 110 interacts with processing section 106 using VF 111, in particular sending graphics operations to processing section 106 and receiving arbitrary response data or control information. Similarly, the processor 102 assigns VM 112 to processing section 108 and assigns VF 113 to VM 112. Therefore, VM112 interacts with processing unit 108 using VF113.

[0020] Since processing sections 106 and 108 are spatially separated from VMs 110 and 112, each processing section can be reset without affecting the operation of the other sections. Accordingly, each of VF111 and 113 is configured to directly send a reset request to processing sections 106 and 108, respectively, when it detects one or more specified reset conditions. That is, when sending a reset request, VF111 and 113 bypass the host device driver 116 and hypervisor 117, and therefore omit sending an interrupt or other communication to the host device driver 116 or hypervisor 117 to indicate the requested reset, and VF111 and 113 do not rely on the host device driver 116 or hypervisor 117 to trigger or control the requested reset. Because the host device driver 116 and hypervisor 117 are bypassed, the overhead associated with the reset process is reduced and the isolation between VM110 and VM112 is enhanced. For example, a malicious VM cannot accept a reset request and affect the performance of another VM, so this increased isolation also improves security between VF111 and VF113.

[0021] To illustrate the reset sequence, in some embodiments, the VF111 detects a stall in the processing unit 106, for example, because the processing unit 106 has not sent an expected message or response to the local device driver 118 within a specified time. In response to detecting that the processing unit 106 has stalled, the local device driver 118 prepares the VM110 for a device reset, and once the preparation is complete (for example, by notifying any software in the VM110 of the reset), it sends a message to the VF111 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 executes the specified reset sequence on the processing unit 106 in response to the reset request. Once 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 on the VM110 that the reset is complete. Thus, the VF111 directly handles the reset of the processing unit, bypassing the host device driver 116 and the hypervisor 117.

[0022] Figure 2 is a block diagram of one example of directly resetting the processing portion 106 of the processing unit 104 according to several embodiments. In the illustrated example, the processing portion 106 is in a stall state, in other words, the processing portion 106 is hung. Upon detecting the stall state, the local device driver 118 attempts to reset the processing portion 106. Therefore, 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.

[0023] When ready (for example, by notifying any hardware of the processing unit 106 of a reset), the local SMU 122 sends a reset request 221 directly to the processing unit 106, bypassing the host device driver 116. In response to the reset request 221, the processing unit 106 executes the reset sequence indicated by the reset request 221. The reset sequence clears any stalled state in the processing unit 106, so that it is no longer hung and is ready 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 that the reset is complete. This completes the handshake 220. Thus, in the example in Figure 2, the processing unit 106 is reset directly by the local SMU 122. In other words, the local SMU 122 does not use the virtualization 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 unit 106. Instead, it bypasses the host device driver 116 and the hypervisor 117, thereby reducing the overhead associated with the reset process and improving the overall processing efficiency of the processing system 100.

[0024] As described above, in some embodiments, the processing unit 104 is a GPU, and the processing parts 106 and 108 implement different rendering engines. Examples of several embodiments are shown in Figure 3. In particular, Figure 3 shows a GPU 304 corresponding to the processing unit 104 in Figure 1. The GPU 304 includes GPU chiplets 306 and 308, which correspond to the processing parts 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 with one or more bridge chips (if any) such that the GPU 304 can be used (e.g., addressable) as 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 in a wafer or within a wafer and later separated from the wafer (e.g., when the wafer is diced), and in many cases, multiple ICs are simultaneously manufactured within a wafer. ICs and optionally discrete circuits, and optionally other components (such as non-semiconductor packaging substrates including printed circuit boards, interposers, and optionally others) are assembled within the multi-die processor.

[0026] In various embodiments, the GPU 304 includes one or more base IC dies that employ processing stacked dielets according to some embodiments. The base die is formed as a single semiconductor chip package that includes N communicatively coupled stacked dielets. For example, in the illustrated embodiment, the GPU 304 includes two dielets, designated dielets 306 and 308. Although various embodiments are described below in the context of specific GPU dielets for purposes of illustration and explanation, it should be recognized 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. Further, in some embodiments, the GPU 304 is incorporated into the same semiconductor chip package as the processor 102 such that the processing system 100 is incorporated into a single semiconductor chip package.

[0027] In various embodiments, as used herein, the term "chiplet" refers to any device that, without limitation, includes the following characteristics: 1) The chiplet includes an active silicon die that includes at least a portion of the computing logic used to solve a complete problem (i.e., the computational workload is distributed across multiple ones of these active silicon dies). 2) The chiplets are packaged together as a monolithic unit on the same substrate. 3) The programming model used to control a particular set of chiplets maintains the concept that these individual computational dies (e.g., a set of graphics processing stacked die chiplets) are a single monolithic unit. That is, each chiplet in a particular set is not exposed as an individual device to an application that uses the set of chiplets to process a computational workload. Instead, the set of chiplets is collectively exposed to the application such that the set of chiplets appears to the application 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. Further, 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 an external system memory module, such as a dynamic random access memory (DRAM) module.

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

[0029] For illustrative purposes, in the example in Figure 3, VF111 is assigned to rendering engine 324 and VF113 is assigned to rendering engine 325. In response to a stall in rendering engine 324, VF111 directly resets rendering engine 324 in the same manner as described with respect to Figure 2. In particular, upon detection of a stall in rendering engine 324, the local device driver 118 performs a handshake 220 with the local SMU 122, and once the handshake 220 is complete, sends a reset request 221 to rendering engine 324. In response to the reset request 221, rendering engine 324 executes the specified reset sequence, thus clearing the stall state and preparing rendering engine 324 to execute additional graphics commands.

[0030] Simultaneously with VF111 directly resetting rendering engine 324, VF113 sends a draw command 322 generated by VM112 to rendering engine 325. In response to the draw command 322, rendering engine 325 performs a set of actions indicated by the command. In at least some embodiments, rendering engine 325 executes these commands at the same time as rendering engine 324, which performs a reset sequence in response to a reset request 221. Thus, in the example of Figure 3, rendering engine 324 is reset independently of and at the same time as rendering engine 325, which executes the draw command 322.

[0031] Figure 4 shows a flowchart of Method 400, a virtual function for directly resetting the processing portion of a processing unit, in several embodiments. Method 400 is described with respect to an exemplary implementation in the processing system 100 of Figure 1. However, it will be understood that in other embodiments, Method 400 may be implemented in processing systems having a configuration different from that of the processing system 100.

[0032] In block 402, the host device driver 116 assigns VF111 and 113 for VM110 and 112 to processing units 106 and 108, respectively. In block 404, the local device driver 118 detects an error in processing unit 106, such as a notification that processing unit 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 processing unit 106, and thus resets processing unit 106 directly, independently of processing unit 108, bypassing the device driver 116.

[0033] As disclosed herein, in some embodiments, the method includes 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 initiates a reset sequence for the processing portion of the processing unit associated with the virtual function, the initiation of which bypasses the host driver of the processing system. In one embodiment, the reset sequence includes a handshake between the local SMU and the device driver of the virtual machine. In another embodiment, the initiation bypasses the host driver of the processing system. In yet another embodiment, the processing unit includes a plurality of semiconductor dies, and a portion of the processing unit includes any of the plurality of dies.

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

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

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

[0037] In some embodiments, the processing system includes a processing unit and a processor that executes virtual machines and virtual functions associated with the virtual machines, wherein, upon detecting a reset condition, the processing unit's local system management unit (SMU) initiates a reset sequence for the processing portion of the processing unit associated with the virtual function, the reset sequence bypassing the processing system's host driver. In one embodiment, the reset sequence includes a handshake between the local SMU and the virtual machine's device driver. In another embodiment, the reset sequence bypasses the processing system's hypervisor.

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

[0039] In some embodiments, certain aspects of the technology described above are implemented by one or more processors of a processing system that executes the software. The software includes one or more sets of executable instructions, which are stored in a non-temporary computer-readable storage medium or otherwise clearly embodied. The software may also include instructions and specific data, which, when executed by one or more processors, operate the one or more processors to execute one or more aspects of the technology described above. Non-temporary computer-readable storage mediums 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 (one or more). Executable instructions stored in a non-temporary computer-readable storage medium can be implemented as source code, assembly language code, object code, or other instruction forms that can be interpreted or otherwise executed by one or more processors.

[0040] In addition to the foregoing, it should be noted that not all activities or elements described in the summary are required, and certain activities or parts of devices may not be required, and 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 does not necessarily indicate 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 understand that various modifications and variations can be made without departing from the scope of the invention as described in the claims. Therefore, the specification and drawings should be considered illustrative rather than restrictive, and all of these variations are intended to fall within the scope of the invention.

[0041] Benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, benefits, advantages, solutions to problems, and features that may give rise to or manifest any benefits, advantages, or solutions are not to be construed as essential, necessary, or indispensable features to any or all of the claims. Furthermore, the disclosed invention can be modified and implemented in different but similar ways, in ways that are obvious to those skilled in the art who are interested in the teachings of this specification; therefore, the specific embodiments described above are merely illustrative. There are no limitations to the details of the configuration or design shown herein beyond those described in the appended claims. Accordingly, the specific embodiments described above may be modified or altered, and it is clear that all such modifications are within the scope of the disclosed invention. Accordingly, the protection sought herein is described in the appended claims.

Claims

1. It is a method, To detect the reset conditions in the virtual functions of a virtual machine executed in a processing system, In response to detecting the reset condition, the local system management unit (SMU) of the processing unit initiates a reset sequence for the processing portion of the processing unit associated with the virtual function, the initiation of which bypasses the host driver of the processing system. method.

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

3. The aforementioned initiation bypasses the hypervisor of the processing system. The method according to claim 1.

4. The processing unit includes a plurality of semiconductor dies, and the processing portion of the processing unit includes any of the plurality of semiconductor dies. The method according to claim 1.

5. The reset sequence includes a reset sequence for resetting one of the plurality of semiconductor dies independently of resetting the other semiconductor dies. The method according to claim 4.

6. The processing unit is spatially divided into a plurality of processing parts, including the processing part. The method according to claim 1.

7. Each of the aforementioned multiple processing units is assigned to a different virtual function from among the multiple virtual functions, including the aforementioned virtual function. The method according to claim 6.

8. A processing system, Processing unit and A processor that executes a virtual machine and virtual functions associated with the virtual machine, wherein the local system management unit (SMU) of the processing unit initiates a reset sequence for the processing portion of the processing unit associated with the virtual function upon detection of a reset condition, The reset sequence bypasses the host driver of the processing system. Processing system.

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

10. The reset sequence bypasses the 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 of the plurality of semiconductor dies. The processing system of claim 8.

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

13. The processing unit is spatially divided into multiple processing parts. The processing system of claim 8.

14. Each of the aforementioned multiple processing units is assigned to a different virtual function from among the multiple virtual functions. The processing system of claim 13.

Images