Hardware-based protection of virtual function resources
A state machine manages GPU resource access to prevent corruption and race conditions by controlling access to subsets based on the processing unit's state, ensuring coordinated and secure VF operations.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- ATI TECHNOLOGIES ULC
- Filing Date
- 2021-12-07
- Publication Date
- 2026-06-19
AI Technical Summary
Simultaneous access by host drivers and virtual functions (VFs) to GPU resources can lead to corruption and race conditions due to uncoordinated writes, particularly during initialization, reinitialization, and reset processes.
Implementing a state machine that selectively enables access to subsets of GPU resources (framebuffer, context registers, and mailbox registers) based on the operating state of the processing unit, ensuring coordinated access and minimizing corruption risks.
Reduces corruption and race conditions by controlling access to GPU resources based on the processing unit's state, enhancing resource integrity and stability during VF operations.
Smart Images

Figure 0007876526000001 
Figure 0007876526000002 
Figure 0007876526000003
Abstract
Description
[Background technology]
[0001] Processing units such as graphics processing units (GPUs) support virtualization, which allows multiple virtual machines to use the processing unit's hardware resources. Each virtual machine runs as a separate process that uses the processing unit's hardware resources. Some virtual machines implement operating systems that allow them to emulate actual machines. Other virtual machines are designed to run code in a platform-independent environment. A hypervisor creates and runs virtual machines, which are also referred to as guest machines or guests. The virtual environment implemented on the processing unit provides virtual functions to other virtual components implemented on the physical machine. A single physical function implemented on the processing unit is used to support one or more virtual functions. The physical function allocates virtual functions to different virtual machines on the physical machine on a time-slice basis. For example, the physical function allocates the first virtual function to the first virtual machine in the first time interval, and the second virtual function to the second virtual machine in the second subsequent time interval. In some cases, the physical functions within a processing unit may support as many as 31 virtual functions, while in other cases, more or fewer virtual functions may be supported. The Single Root Input / Output Virtualization (SR IOV) specification allows multiple virtual machines (VMs) to share a processor interface to a single bus, such as a Peripheral Component Interconnect Express (PCIe) bus. Components access virtual functions by sending requests through the bus.
[0002] The present disclosure can be better understood by reference to the accompanying drawings, and its various 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 including a graphics processing unit (GPU) that implements sharing of physical functions in a virtualized environment according to some embodiments. [Figure 2] FIG. 2 is a block diagram of a processing system that provides selective access to resources by virtual functions (VFs) according to some embodiments. [Figure 3] FIG. 3 is a block diagram of a state machine used to determine the state of a VF and selectively enable resource access by the VF according to some embodiments.
Modes for Carrying Out the Invention
[0004] GPU hardware resources are partitioned according to SR-IOV using physical functions (PFs) and one or more virtual functions (VFs). Each virtual function is associated with a single physical function, thereby the virtual function is implemented using the physical resources and circuitry of the associated physical function. In the native (host OS) environment, physical functions are used by native user-mode and kernel-mode drivers, and all virtual functions are disabled. All GPU resources are mapped to physical functions via trusted access. In the virtual environment, physical functions are used by the hypervisor (host VM), and the GPU exposes a certain number of virtual functions according to the PCIe SR-IOV standard, such as one virtual function per guest VM. Each virtual function is assigned to the guest VM by the hypervisor. A subset of GPU resources is mapped to virtual functions, and this subset is partitioned to include the framebuffer, context registers, doorbell aperture, and one or more mailbox registers used for VF-PF synchronization. During VF initialization, access to the framebuffer, context registers, and doorbell assigned to the VF is enabled by the host driver. However, in some cases, the host driver simultaneously writes information to the frame buffer, context register, or doorbell on behalf of the VF that owns these resources. Therefore, continuous, uncoordinated writes to resources by the VF and the host driver can corrupt the contents of the resources or cause race conditions. Corruption or race conditions can also occur during VF resets.
[0005] Figures 1 to 3 disclose techniques for reducing or avoiding corruption and race conditions in a processing unit resulting from simultaneous access by the host driver and VFs to resources assigned to VFs, by selectively enabling access by virtual functions (VFs) to a subset of resources depending on the operating state of the processing unit. In some embodiments, the subset of resources includes a framebuffer, one or more context registers, a doorbell, and one or more mailbox registers. The host driver enables VF access to different subsets of resources when the processing unit is in different states. The states include a first (default) state in which VF access to the mailbox registers is allowed while VF access to the framebuffer, context registers, and doorbell is disabled. In a second state, the host driver enables VF access to the framebuffer, context registers, doorbell, and mailbox registers. The second state is used for VF initialization, reinitialization, and reset. In a third state, the host driver selectively enables VF access to a subset of resources based on the risk, security, or threat level associated with the subset. In some embodiments, VF access to the framebuffer and doorbell is enabled in a third set, while VF access to the context registers is disabled due to the relatively high risk associated with enabling access to the context registers. In some embodiments, the processing unit transitions to a first state in response to detection of a driver failure or invalid driver, or a malicious driver. The host driver enables access to the mailbox registers, framebuffer, and doorbell, and disables VF access to other registers, until the VF transitions to a first (default) state, for example, in response to a driver reset or the installation / initialization of a new driver.
[0006] For the sake of clarity, the systems and technologies of this disclosure will be described in the illustrative context of a GPU as a processing unit. However, these systems and technologies are not limited to this example, and therefore, the reference to a GPU applies equally to any of the various parallel processors (e.g., vector processors, graphics processing units (GPUs), general-purpose GPUs (GPGPUs), non-scalar processors, highly parallel processors, artificial intelligence (AI) processors, inference engines, machine learning processors, other multithreaded processing units, etc.).
[0007] Figure 1 is a block diagram of a processing system 100 including a graphics processing unit (GPU) 105 that implements the sharing of physical functions in a virtualized environment, according to several embodiments. The GPU 105 includes one or more GPU cores 106 that independently execute instructions simultaneously or in parallel, and one or more shader systems 107 that support 3D graphics or video rendering. For example, the shader system 107 may be used to improve the visual representation by increasing the graphics rendering frame-per-second score or patching area of rendered images that the graphics engine did not render accurately. A memory controller 108 provides an interface to a frame buffer 109 that stores frames during the rendering process. Some embodiments of the frame buffer 109 are implemented as dynamic random access memory (DRAM). However, the frame buffer 109 can also be implemented using other types of memory, including static random access memory (SRAM), non-volatile RAM, etc. Some embodiments of the GPU105 include other circuits such as an encoder format converter, a multi-format video codec, a display output circuit that provides an interface to a display or screen, an audio coprocessor, and an audio codec for encoding / decoding audio signals.
[0008] The processing system 100 also includes a central processing unit (CPU) 115 for executing instructions. The CPU 115 includes a plurality of processor cores 120, 121, 122 (collectively referred to herein as "processor cores 120-122") that can execute instructions independently, simultaneously, or in parallel. In some embodiments, the GPU 105 operates as a discrete GPU (dGPU) connected to the CPU 115 via a bus 125 (such as a PCI-e bus) and a northbridge 130. The CPU 115 also includes a memory controller 135 that provides an interface between the CPU 115 and memory 140. Some embodiments of memory 140 are implemented as DRAM, SRAM, non-volatile RAM, etc. The CPU 115 executes instructions such as program code 145 stored in memory 140, and the CPU 115 stores information 150 such as the results of the executed instructions in memory 140. Furthermore, CPU115 can initiate graphics processing by issuing a draw call to GPU105. A draw call is a command generated by CPU115 and sent to GPU105 to instruct GPU105 to render an object (or part of an object) within the frame.
[0009] The northbridge 130 is connected to the southbridge 155. The southbridge 155 provides one or more interfaces 160 to peripheral units associated with the processing system 100. Some embodiments of the interface 160 include interfaces to peripheral units such as universal serial bus (USB) devices, general-purpose I / O (GPIO), and serial peripheral bus interfaces such as SATA, SPI, I2C, etc., for hard disk drives.
[0010] The GPU 105 includes a GPU virtual memory management unit with address translation controller (GPU MMU ATC) 165, and the CPU 115 includes a CPU MMU ATC 170. The GPU MMU ATC 165 and CPU MMU ATC 170 perform translation from virtual memory addresses (VA) to physical memory addresses (PA) using multilevel translation logic and a set of translation tables maintained by the operating system kernel mode driver (KMD). Therefore, each application process running on the main OS or within a guest OS has its own virtual address space for CPU operation and GPU rendering. Thus, the GPU MMU ATC 165 and CPU MMU ATC 170 support virtualization of the GPU and CPU cores. The GPU 105 has its own memory management unit (MMU), which translates per-process GPU virtual addresses to physical addresses. Each process has a separate CPU and GPU virtual address space using a separate page table. The video memory manager manages the GPU virtual address space for all processes, overseeing the allocation, scaling, updating, and retention of memory pages, as well as the release of page tables.
[0011] Furthermore, the GPU 105 includes one or more physical functions (PFs) 175. In some embodiments, the physical functions 175 are hardware-accelerated functions such as multimedia decoding, multimedia coding, video decoding, video coding, audio decoding, and audio coding. The virtual environment implemented in memory 140 supports a set of physical functions and virtual functions (VFs) exposed to the guest VM. The GPU 105 further includes a set of resources (not shown in Figure 1 for clarity) that store information associated with processing performed by kernel-mode units. A subset of the set of resources is allocated to store information associated with virtual functions. In some embodiments, a subset of GPU resources is mapped to virtual functions, and the subset is divided to include a frame buffer, context registers, doorbell aperture, and one or more mailbox registers used for VF PF synchronization. The physical functions 175 are executed on behalf of any of the guest VM's virtual functions based on the information stored in the corresponding subsets of the subsets, as described in detail herein.
[0012] In some embodiments of the GPU105, a host driver is executed, which selectively enables the VF to access resources based on the operating state of the GPU105. For example, the host driver enables access to the mailbox register for all states of the VF running on the GPU105. However, the host driver disables access to the framebuffer, context register, and doorbell during the VF's first (default) state. The host driver enables access to the framebuffer, context register, and doorbell during the VF's second state, allowing the VF to perform operations related to VF initialization, reinitialization, or reset. The VF is typically running in a third state, and therefore the host driver selectively enables access to a subset of resources based on the risk level, security level, or threat level associated with that subset. In some embodiments of the host driver, access to the framebuffer and doorbell is enabled, but access to the context register is disabled due to the relatively high risk / threat of exposing the context register to the VF at runtime compared to the lower risk / threat associated with the framebuffer, doorbell, and mailbox register. In some embodiments, the GPU 105 implements a state machine (not shown in Figure 1 for clarity) that manages or changes the state of the VF within the GPU 105.
[0013] Figure 2 is a block diagram of a processing system 200 that enables selective access to resources by VFs in several embodiments. The processing system 200 is used to implement several embodiments of the processing system 100 shown in Figure 1. In the illustrated embodiments, the processing system 200 implements a host driver 205, a physical function circuit 210, and one or more virtual functions (VFs) 215 that run on the physical function circuit 210, as described herein.
[0014] The processing system 200 implements a set 220 of resources assigned to the VF215 running on the physical function circuit 210. In the illustrated embodiment, the set 220 is divided into subsets of resources assigned to different VF215s. For example, the subset of resources reserved for the framebuffer is divided into a framebuffer subset 221 assigned to the VF215 and one or more other framebuffer subsets 222 assigned to other virtual functions. The subset of resources reserved for the context register is divided into a context subset 225 assigned to the VF215 and one or more other context subsets 226 assigned to other virtual functions. The subset of resources reserved for the doorbell is divided into a doorbell 231 assigned to the VF215 and one or more other doorbells 232 assigned to other virtual functions. The subset of resources reserved for mailbox registers is divided into mailbox subset 235 allocated to VF215 and one or more other mailbox subsets 236 allocated to other virtual functions.
[0015] During the initialization of VF215 (or other virtual functions), the host driver 205 provides VF215 (or other virtual functions) with signaling 240 that selectively enables VF215 to access the frame buffer 221, context register 225, doorbell 231, and mailbox register 235 assigned to VF215. However, in some cases, the host driver 205 simultaneously writes information to one or more of the frame buffer 221, context register 225, or doorbell 231 on behalf of VF215, which owns these registers. Therefore, uncoordinated writes to resources by VF215 and the host driver 205 may corrupt the contents of the resources or cause race conditions. Furthermore, corruption or race conditions may occur during the reset of VF215 and the corresponding resources 221, 225, and 231. Therefore, the host driver 205 uses signaling 240 to selectively enable a subset of the set of resources 220 based on the operating state of the corresponding VF215.
[0016] Figure 3 is a block diagram of a state machine 300 used in several embodiments to determine the state of a VF and selectively enable resource access by the VF. The state machine 300 is implemented in several embodiments of the processing system 100 shown in Figure 1 and the processing system 200 shown in Figure 2. In the illustrated embodiments, the state machine 300 provides a set of states and defines transitions between the states of the VF. The set of states includes a default state 305, which is applied to the VF when the conditions for other states are not met by the VF. The set of states also includes an "all access" state 310 used for initializing, reinitializing, or resetting the VF, and a "partial access" state 315 used during the runtime of the VF.
[0017] During operation, the state machine 300 places the VF in the default state 305 if there is no other suitable state for the VF. For example, the state machine 300 places the VF in the default state 305 in response to a world switch when the processing unit stops or pauses the execution of the VF and switches to the execution of another VF. In the default state 305, the host driver disables access to the frame buffer, context registers, and doorbell. The host driver also enables access to the mailbox registers in the default state 305 to support communication between the VF and the PF implementing the VF.
[0018] The state machine 300 changes the state of the VF to the "all-access" state 310 during VF initialization, reinitialization, or reset. For example, the state machine 300 places the VF in the "all-access" state 310 in response to the processing unit initializing the VF. The host driver enables access to the frame buffer, context register, doorbell, and mailbox register when the VF is in the "all-access" state 310. Thus, the VF can perform configuration operations related to starting or resetting the VF by writing information to the frame buffer, context register, doorbell, or mailbox register as needed. The risk of exposing the contents of the registers is also reduced by limiting the "all-access" state 310 to the time interval used for VF initialization, reinitialization, or reset.
[0019] However, if the state machine 300 detects, for example, a failure in the driver associated with the VF, or an invalid, unsupported, or malicious driver, in response to initializing the VF and its corresponding driver, the state machine 300 transitions the VF from the "all access" state 310 to the default state 305. In the default state 305, the host driver disables access to the frame buffer, context registers, and doorbell to prevent corruption or malicious modification of the contents of these resources. The state machine 300 remains in the default state 305 until the current driver is reinitialized by a valid driver or a new driver is loaded. Once the current driver is reinitialized or a new driver is loaded, the state machine 300 transitions to the "all access" state 310 to continue initializing, reinitializing, or resetting the VF.
[0020] The state machine 300 transitions from the "full access" state 310 to the "partial access" state 315 in response to the completion of VF initialization, reinitialization, or reset. The "partial access" state 315 is used during the runtime of the VF, and access to a subset of resources is determined based on the risk level, security level, or threat level associated with the subset. Some embodiments of the state machine 300 enable access to the framebuffer, and the doorbell is enabled in the "partial access" state 315, but disable access to the context registers due to the relatively high risk associated with enabling access to the context registers. However, in other embodiments, other combinations of registers are enabled or disabled. In response to a driver unload event, the state machine 300 returns the VF state to the full access state 310, and transitions to the default state 305 in response to the end of VF usage notifications or the detection of the end of VF usage.
[0021] However, if the state machine 300 receives notification that VF usage has ended, the state machine 300 transitions the VF from the "all access" state 310 to the default state 305. In the default state 305, the host driver disables access to the framebuffer, context registers, and doorbell to prevent corruption or malicious modification of the contents of these resources. The state machine 300 remains in the default state 305 until a new driver is loaded, at which point the state machine 300 transitions to the "all access" state 310 and continues initializing, reinitializing, or resetting the VF.
[0022] As disclosed herein, in some embodiments, the device includes a plurality of resources configured to store information, a physical functional circuit configured to execute a virtual function using the information stored in the plurality of resources, and a processing unit, the processing unit configured to run a host driver that selectively enables the virtual function to access the plurality of resources based on the operating state of the processing unit. In one embodiment, the processing unit is configured to selectively enable the virtual function to access different combinations of subsets of the plurality of resources simultaneously with processing units in different operating states. In another embodiment, the subsets of the plurality of resources include a first subset for implementing a frame buffer, a second subset for implementing at least one context register, a third subset for implementing a doorbell, and a fourth subset for implementing at least one mailbox register. In yet another embodiment, the operating state of the processing unit includes any of a first state which is the default state of the virtual function, a second state which is used for initializing, reinitializing, and resetting the virtual function, and a third state which is the virtual function being executed on the physical functional circuit.
[0023] In one embodiment, the host driver is configured to disable access by the virtual function to a first, second, and third subset, and to enable access by the virtual function to a fourth subset, depending on whether the virtual function is in a first state. In another embodiment, the host driver is configured to enable access by the virtual function to a first, second, third, and fourth subset, depending on whether the virtual function is in a second state. In yet another embodiment, the host driver is configured to enable access by the virtual function to a subset of resources based on at least one of the risk level, security level, and threat level associated with the subset, depending on whether the virtual function is in a third state. In yet another embodiment, the host driver is configured to enable access by the virtual function to a first, third, and fourth subset, and to disable access by the virtual function to a second subset, depending on whether the virtual function is in a third state.
[0024] In some embodiments, the method includes executing a virtual function on a physical functional circuit using information stored in a plurality of resources configured to store information, and selectively enabling access to the plurality of resources by the virtual function in a host driver running on a processing unit based on the operating state of the processing unit. In another embodiment, selectively enabling access to the plurality of resources includes selectively enabling access to different combinations of subsets of the plurality of resources by the virtual function at the same time that the processing unit is in different operating states. In yet another embodiment, the subsets of the plurality of resources include a first subset for implementing a frame buffer, a second subset for implementing at least one context register, a third subset for implementing a doorbell, and a fourth subset for implementing at least one mailbox register.
[0025] In one embodiment, the operating state of the processing unit includes a first state, which is the default state of the virtual function; a second state of the virtual function used for initialization, reinitialization, and resetting the virtual function; and a third state of the virtual function in which the virtual function is running on a physical functional circuit. In another embodiment, selectively enabling access to multiple resources includes disabling access by the virtual function to a first subset, a second subset, and a third subset, and enabling access by the virtual function to a fourth subset, depending on whether the virtual function is in the first state. In yet another embodiment, selectively enabling access to multiple resources includes enabling access by the virtual function to a first subset, a second subset, a third subset, and a fourth subset, depending on whether the virtual function is in the second state. In yet another embodiment, selectively enabling access to multiple resources includes enabling access by the virtual function to a subset of resources based on at least one of the risk level, security level, and threat level associated with the subset, depending on whether the virtual function is in the third state. In another embodiment, selectively enabling access to multiple resources includes enabling access by the virtual function to a first subset, a third subset, and a fourth subset, and disabling access by the virtual function to a second subset, depending on whether the virtual function is in a third state.
[0026] In some embodiments, the apparatus includes a physical function circuit configured to execute a virtual function using information stored in a plurality of resources, a state machine configured to determine the state of the virtual function, and a processing unit configured to execute a host driver that selectively enables access by the virtual function to a plurality of resources based on the state of the virtual function. In one aspect, the host driver is configured to selectively change access by the virtual function to a subset of the plurality of resources in response to the state machine changing the state of the virtual function. In another aspect, the subset of the plurality of resources includes a first subset for implementing a frame buffer, a second subset for implementing at least one context register, a third subset for implementing a doorbell, and a fourth subset for implementing at least one mailbox register. In yet another aspect, the state of the virtual function includes any one of a first state that is the default state of the virtual function, a second state of the virtual function used for initialization, re-initialization and reset of the virtual function, and a third state of the virtual function while the virtual function is being executed on the physical function circuit.
[0027] Computer-readable storage media include any non-temporary storage media or combination of non-temporary storage media that are accessible by a computer system during use to provide instructions and / or data to the computer system. Such storage media may include, but are not limited to, optical media (e.g., compact discs (CDs), digital versatile discs (DVDs), Blu-ray® discs), magnetic media (e.g., floppy disks, magnetic tapes, magnetic hard drives), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or microelectromechanical system (MEMS) based storage media. Computer-readable storage media (e.g., system RAM or ROM) may be built into the computing system, computer-readable storage media (e.g., magnetic hard drives) may be permanently mounted to the computing system, computer-readable storage media (e.g., optical disks or Universal Serial Bus (USB) based flash memory) may be detachably mounted to the computing system, and computer-readable storage media (e.g., network-accessible storage (NAS)) may be connected to the computer system via a wired or wireless network.
[0028] In some embodiments, certain aspects of the technologies described above are implemented by one or more processors of a processing system that executes software. The software includes one or more sets of executable instructions stored on a non-transitory computer-readable storage medium or otherwise tangibly embodied. The software may include instructions and specific data, and when executed by one or more processors, the instructions and specific data operate one or more processors to perform one or more aspects of the technologies described above. The non-transitory computer-readable storage medium may include, for example, magnetic or optical disk storage devices, solid state storage devices such as flash memory, cache, random access memory (RAM), or other non-volatile memory device(s), among others. The executable instructions stored on the non-transitory computer-readable storage medium may be implemented in source code, assembly language code, object code, or other instruction formats interpretable or otherwise executable by one or more processors.
[0029] In addition to what has been described above, note that not all activities or elements described in the general description are required, some activities or parts of a particular device may not be required, one or more additional activities may be performed, and one or more additional elements may be included. Further, the order in which activities are recited is not necessarily the order in which they are performed. Also, the concepts have been described with reference to particular embodiments. However, those skilled in the art will understand that various changes and modifications can be made without departing from the scope of the invention as set forth in the claims. Accordingly, the specification and drawings are to be considered in an illustrative rather than a limiting sense, and all such modifications are intended to be included within the scope of the invention.
[0030] 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 device, Multiple hardware resources of a processing unit configured to store information, comprising multiple hardware resources including a subset of multiple resources, A physical function circuit configured to execute a virtual function using information stored in the aforementioned multiple hardware resources, A processing unit is provided, The aforementioned processing unit is The state of the virtual function is determined from a set of states associated with corresponding combinations of subsets of resources among the subsets of the aforementioned multiple resources, For each subset of the multiple resources, the host driver is configured to execute a host driver that selectively enables or disables the virtual function's access to the subset of resources based on the corresponding combination of the subset of resources associated with the determined state of the virtual function. Device.
2. The subset of the plurality of resources includes a first subset for implementing a framebuffer, a second subset for implementing at least one context register, a third subset for implementing a doorbell, and a fourth subset for implementing at least one mailbox register. The apparatus according to claim 1.
3. The determined state of the virtual function includes any of the following: a first state which is the default state of the virtual function; a second state of the virtual function used for initialization, reinitialization, and resetting of the virtual function; and a third state of the virtual function in which the virtual function is executed on the physical function circuit. The apparatus according to claim 2.
4. The host driver is configured to disable access by the virtual function to the first subset, the second subset, and the third subset, and to enable access by the virtual function to the fourth subset, depending on whether the virtual function is in the first state. The apparatus according to claim 3.
5. The host driver is configured to enable access by the virtual function to the first subset, the second subset, the third subset, and the fourth subset, depending on whether the virtual function is in the second state. The apparatus according to claim 3 or 4.
6. The host driver is configured to selectively enable or disable access by the virtual function to a subset of resources corresponding to the subset of resources, based on at least one of the risk level, security level, and threat level associated with the subset, depending on whether the virtual function is in the third state. The apparatus according to claim 3, 4, or 5.
7. The host driver is configured to enable access by the virtual function to the first subset, the third subset, and the fourth subset, and to disable access by the virtual function to the second subset, depending on whether the virtual function is in the third state. The apparatus according to claim 6.
8. It is a method, In a physical functional circuit, a virtual function is executed using information stored in multiple hardware resources of a processing unit configured to store information, wherein the multiple hardware resources include a subset of multiple resources. The state of the virtual function is determined from a set of states, wherein each state in the set of states is associated with a corresponding combination of a subset of resources from a subset of the plurality of resources. A host driver running on a processing unit includes, for each subset of the plurality of resources, selectively enabling or disabling access by the virtual function to a subset of the plurality of resources based on a corresponding combination of the subset of resources associated with a determined state of the virtual function, method.
9. The subset of the plurality of resources includes a first subset for implementing a framebuffer, a second subset for implementing at least one context register, a third subset for implementing a doorbell, and a fourth subset for implementing at least one mailbox register. The method of claim 8.
10. The determined state of the virtual function includes any of the following: a first state which is the default state of the virtual function; a second state of the virtual function used for initialization, reinitialization, and resetting of the virtual function; and a third state of the virtual function in which the virtual function is executed on the physical function circuit. The method of claim 9.
11. Selectively enabling or disabling access to a subset of resources includes, depending on whether the virtual function is in the first state, disabling access by the virtual function to the first subset, the second subset and the third subset, and enabling access by the virtual function to the fourth subset. The method of claim 10.
12. Selectively enabling or disabling access to a subset of resources includes enabling the virtual function to access the first subset, the second subset, the third subset, and the fourth subset, depending on whether the virtual function is in the second state. The method according to claim 10 or 11.
13. Selectively enabling or disabling access to a subset of resources includes enabling the virtual function to access a subset of the plurality of resources that corresponds to a subset of resources, based on at least one of the risk level, security level, and threat level associated with the corresponding subset of resources, depending on whether the virtual function is in the third state. The method of claim 10, 11, or 12.