Service continuity for virtualized devices after resuming from hibernation

Abstract

Techniques are provided for operating an auxiliary processing device, including: requesting, based on a first request received from a client specifying a handle, that work be performed via a first auxiliary processing device mapped to the handle; updating, upon resuming from hibernation, the mapping of the handle to reference a second auxiliary processing device; and, based on a second request received from the client specifying the handle, that work be performed via the second auxiliary processing device.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to pending U.S. patent application Ser. No. 18 / 080,588, filed Dec. 13, 2022, which is incorporated herein by reference in its entirety. [Background technology]

[0002] Computer virtualization refers to the decoupling of physical hardware from logical devices, which provides flexibility in the use of physical hardware capabilities. Improvements in the operations associated with virtualization are constantly being made.

[0003] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which: [Brief explanation of the drawings]

[0004] [Figure 1] FIG. 1 is a block diagram of an example computing device capable of implementing one or more features of the present disclosure. [Figure 2] FIG. 1 illustrates details of devices related to virtualization, according to an example. [Figure 3] FIG. 1 illustrates a set of pre-hibernation actions, according to an example. [Figure 4] FIG. 1 illustrates a set of operations for waking up an operation after hibernation and performing an action using an auxiliary processing device, according to one example. [Figure 5] 1 is a flow diagram of a method for operating an auxiliary processing device in a virtualized environment, according to an example. DETAILED DESCRIPTION OF THE INVENTION

[0005] Techniques are provided for operating an auxiliary processing device, including: requesting, based on a first request received from a client specifying a handle, that work be performed via a first auxiliary processing device mapped to the handle; updating, upon resuming from hibernation, the mapping of the handle to reference a second auxiliary processing device; and, based on a second request received from the client specifying the handle, that work be performed via the second auxiliary processing device.

[0006] 1 is a block diagram of an exemplary computing device 100 capable of implementing one or more features of the present disclosure. In various examples, computing device 100 may be, for example, but not limited to, a computer, a gaming device, a handheld device, a set-top box, a television, a mobile phone, a tablet computer, or other computing device. Device 100 includes, but is not limited to, one or more processors 102, memory 104, one or more auxiliary devices 106, and storage 108. An interconnect 112, which may be a bus, a combination of buses, and / or any other communication component, communicatively links one or more processors 102, memory 104, one or more auxiliary devices 106, and storage 108.

[0007] In various alternatives, the one or more processors 102 include a central processing unit (CPU), a graphics processing unit (GPU), a CPU and a GPU located on the same die, or one or more processor cores, each of which may be a CPU, a GPU, or a neural processor. In various alternatives, at least a portion of the memory 104 is located on the same die as one or more of the one or more processors 102, such as on the same chip or in an interposer configuration, and / or at least a portion of the memory 104 is located independently of the one or more processors 102. The memory 104 may include volatile or non-volatile memory (e.g., random access memory (RAM), dynamic RAM, cache).

[0008] The storage 108 includes fixed or removable storage devices (e.g., but not limited to, hard disk drives, solid-state drives, optical disks, flash drives). The one or more auxiliary devices 106 include, but are not limited to, one or more auxiliary processors 114 and / or one or more input / output (IO) devices. The auxiliary processor 114 includes, but is not limited to, a processing unit capable of executing instructions such as a central processing unit, a graphics processing unit, a parallel processing unit capable of performing computational shader operations in a single-instruction, multiple-data format, a multimedia accelerator such as a video encoding or decoding accelerator, or any other processor. Any auxiliary processor 114 may be implemented as a programmable processor that executes instructions, a fixed-function processor that processes data according to fixed hardware circuitry, a combination thereof, or any other type of processor.

[0009] The one or more IO devices 116 include one or more input devices such as a keyboard, keypad, touch screen, touchpad, detector, microphone, accelerometer, gyroscope, biometric scanner, or network connection (e.g., a wireless local area network card for transmitting and / or receiving wireless IEEE 802 signals), and / or one or more output devices such as a display, speaker, printer, haptic feedback device, one or more lights, antenna, or network connection (e.g., a wireless local area network card for transmitting and / or receiving wireless IEEE 802 signals).

[0010] 2 illustrates details of device 100 related to virtualization, according to an example. Processor 102 supports multiple virtual machines, which are virtualized instances of actual computing devices. A dedicated host virtual machine 202 is not a "general-purpose" VM like guest VM 204; instead, it performs support functions for virtualization of device 100 for guest VM 204. Hypervisor 206 provides virtualization support to the virtual machines, including a wide variety of functions such as managing resources allocated to the virtual machines, creating and destroying virtual machines, handling system calls, managing access to peripheral devices, managing memory and page tables, and various other functions.

[0011] There is a set of auxiliary processing devices 200. In some examples, the auxiliary processing devices 200 are auxiliary processors 114. In some examples, the auxiliary processing devices 200 are media processors, such as video encoders, video decoders, and / or other media processors. The hypervisor 206 or the host VM 202 configures one or more auxiliary processing devices 200 to communicate with one or more guest virtual machines 204, for example, by linking the guest virtual machines 204 to the auxiliary processing devices. The guest virtual machines 204 communicate with the auxiliary processing devices 200 through one or more virtual functions. A virtual function is an addressing parameter of an interface scheme, such as Peripheral Component Interconnect Express (PCIe), that implements Single Root I / O Virtualization (SRI-IOV) or is compatible with it. To communicate using virtual functions, the guest VM 204 executes communications that explicitly or implicitly identify a particular virtual function of a particular auxiliary processing device 200. In some examples, a routing mechanism, such as an Input / Output Memory Management Unit (IOMMU), routes communications to the appropriate auxiliary processing device 200 and virtual function.

[0012] In some examples, upon initialization, virtual machine 204 links a particular guest physical address to a particular virtual function of a particular auxiliary processing device 200. In some such examples, virtual machine 204 configures auxiliary processing device 200 to link the guest physical address to the virtual function. Thereafter, when virtual machine 204 performs an operation that specifies the guest physical address, such memory transaction is routed (e.g., by an IOMMU) to the specified auxiliary processing device 200 and virtual function.

[0013] Host VM 202 and guest VM 204 have operating system 120. Host VM 202 has management applications 123 and host device drivers 121. Guest VM 204 has applications 126, operating system 120, and guest device drivers 122. These elements control various aspects of the operation of processor 102 and auxiliary processing device (APD) 200.

[0014] As described above, host VM 202 configures the virtualization aspects of APD 200 for guest VMs 204. Accordingly, host VM 202 includes operating system 120, which supports the execution of other elements such as management applications 123 and host device drivers 121. In one example, host device drivers 121 manage parameters related to the mechanism for sharing auxiliary processing devices 200 between different VMs, controlling various parameters including which auxiliary processing devices 200 are assigned to which guest VMs 204 and which work requested by a particular VM 204 is performed on the auxiliary processing devices.

[0015] Although host device driver 121 is described as being included in host VM 202, in other embodiments, host device driver 121 is included in hypervisor 206. In such embodiments, host VM 202 may not be present, and the functions of host VM 202 may be performed by hypervisor 206.

[0016] Guest VM 204 includes operating system 120, guest device drivers 122, and applications 126. Operating system 120 is any type of operating system that can run on processor 102. Guest device drivers 122 are “native” drivers for APD 200 in that guest device drivers 122 control the operation of one or more auxiliary processing devices 200 for the guest VM 204 in which they are running and send tasks to auxiliary processing devices 200 for processing. Native drivers may be unmodified or modified versions of device drivers for auxiliary processing devices 200 present in a bare metal, non-virtualized computing system.

[0017] The operating systems 120 of the host VM 202 and guest VMs 204 perform the standard functions of an operating system in a virtualized environment, such as communicating with hardware, managing resources and file systems, managing virtual memory, managing the network stack, and many other functions. The guest device driver 122 controls the operation of the auxiliary processing device 200 for any particular guest VM 204, for example, by providing an application programming interface (API) for software (e.g., applications 126) to access various functions of the APD 200. For any particular guest VM 204, the guest device driver 122 controls the functions of the APD 200 associated with that guest VM 204, and not for other VMs.

[0018] Host device driver 121 manages the mapping between auxiliary processing devices 200 and guest VMs 204. More specifically, there may be multiple auxiliary processing devices 200, and fewer than all of the auxiliary processing devices 200 may be visible to any particular guest VM 204. In one example, processor 102 runs four guest VMs 204, and device 100 includes two auxiliary processing devices 200. In this example, host device driver 121 makes one auxiliary processing device 200 visible to the first and second guest VMs 204 but invisible to the third and fourth guest VMs 204, and makes another auxiliary processing device 200 visible to the third and fourth guest VMs 204 but invisible to the first and second guest VMs 204. A guest VM 204 cannot access an auxiliary processing device 200 if the auxiliary processing device 200 is not visible to the guest VM 204, and a guest VM 204 can access an auxiliary processing device 200 if the auxiliary processing device 200 is visible to the guest VM 204.

[0019] The hypervisor 206 assigns auxiliary processing devices 200 to guest VMs 204. In some examples, this assignment occurs during the initialization period of the VMs 204, such as during boot time of the VMs 204 (e.g., when the VMs 204 are first powered on and the operating system goes through its startup sequence). The hypervisor 206 determines which auxiliary processing devices 200 to assign to any particular guest VM 204 in any technically feasible manner. In one example, the hypervisor 206 assigns one auxiliary processing device 200 per guest VM 204. In some such examples, the hypervisor 206 assigns the auxiliary processing devices 200 evenly. In other such examples, the hypervisor 206 assigns the auxiliary processing devices 200 according to the processing capabilities of the auxiliary processing devices 200. Other technically feasible techniques may also be used.

[0020] As a result of allocating an auxiliary processing device 200 to a guest VM 204, the guest VM 204 can access the processing device 200. An entity such as an application 126 or another entity of the VM 204 accesses the processing device 200 through a guest device driver 122. The application 126 identifies the particular auxiliary processing device 200 to access based on an auxiliary processing device handle provided by the guest device driver 122. In one example, the application generates a request for processing by the auxiliary processing device through the auxiliary processing device handle. The application sends the request to the guest device driver 122, which includes a mapping from the auxiliary processing device handle to the physical auxiliary processing device 200 assigned to the guest VM 204. Based on this mapping, the guest device driver 122 sends the request to the auxiliary processing device 200 corresponding to the virtual function, and the auxiliary processing device 200 processes the request.

[0021] Guest VM 204 can perform hibernation. Hibernation involves backing up the operating state of guest VM 204 and powering down guest VM 204. The backed-up state is sufficient to restore the operating state of guest VM 204 once power is restored. These operating states include currently running applications, the state of those applications (e.g., open documents, the currently viewed position within the document, and / or other data loaded into memory for the applications), the state of the operating system, the contents of memory, the state of registers, and other state associated with guest VM 204.

[0022] The VM 204 can be resumed from hibernation. To resume the VM 204 from hibernation, the hypervisor 206 launches the guest 204 VM in the saved state of the guest VM 204. Thus, applications and / or other software recover the state that was saved when hibernation occurred. During the resume process, the hypervisor 206 maps an auxiliary processing device 200 to the guest VM 204. The auxiliary processing device 200 provided to the resumed guest VM 204 may not be the same auxiliary processing device 200 that the guest VM 204 was using when the guest VM 204 hibernated. For example, the operating state of the device 100 may change such that the auxiliary processing device 200 mapped to the guest VM 204 is used by too many guest VMs 204, and therefore the hypervisor 206 may determine that the resuming guest VM should be mapped to a different auxiliary processing device 200. As such, guest device driver 122 performs operations to ensure continuity of the service provided by auxiliary processing device 200. Such operations are described in more detail below.

[0023] 3 illustrates an example set of pre-hibernation operations. The operating system (OS) 120 of the guest VM 204 performs initialization 352, which includes a startup sequence that loads infrastructure software such as device drivers, initializes hardware, and performs other operations. Initialization 352 includes initializing the guest device driver 122 for the auxiliary processing device 200. As part of this initialization, the guest device driver 122 requests available hardware information for the auxiliary processing device 200 (request ID—step 354). The requested information includes which auxiliary processing devices 200 are available for use by the guest VM 204 being initialized. The hypervisor 206 provides this information to the guest device driver 122 in step 356.

[0024] When a client 302 (which may be an application 126 or other entity) wishes to perform work on the auxiliary processing device 200, the client 302 requests a handle 358 for the auxiliary processing device 200 from the guest device driver 122. The guest device driver 122 generates or obtains such a handle and provides the handle to the client 302 in operation 360. The client 302 requests to perform an action on the auxiliary processing device 200 using the handle in operation 362. The guest device driver 122 requests to perform an action on the auxiliary processing device 200 associated with the handle in operation 364. After a period of time, the operating system 120 causes the guest VM 204 to hibernate in operation 366.

[0025] 4 illustrates a set of operations for resuming operations after hibernation and performing actions using auxiliary processing device 200, according to one example. Operating system 120 is triggered to resume 402 from hibernation. In some examples, hypervisor 206 or another entity initiates an initial boot sequence that powers on guest VM 204, which triggers operating system 120 of VM 204 to initiate resume 402. Part of the resume includes hypervisor 206 allocating hardware resources to guest VM 204. Specifically, hypervisor 206 selects an auxiliary processing device 200 to assign to guest VM 204. The auxiliary processing device 200 assigned to guest VM 204 may be different from the auxiliary processing device 200 assigned to guest VM 204 before hibernation.

[0026] During the course of resuming, which includes loading state for OS 120, applications 126, and other operations, OS 120 triggers guest device driver 122 to perform operations to resume from hibernation. As part of this operation, guest device driver 122 requests a new auxiliary processing device 200 in step 404. In some examples, this request is made to hypervisor 206. The purpose of the request is to update information stored by guest device driver 122 regarding which auxiliary processing device 200 is mapped to guest VM 204. More specifically, as described above, hypervisor 206 selects a new auxiliary processing device 200 for guest VM 204 after resuming from hibernation, and the new auxiliary processing device 200 may be different from the auxiliary processing device 200 assigned to guest VM 204 before hibernation. Hypervisor 206 provides the updated auxiliary processing device to guest device driver 122 in operation 406. The guest device driver 122, in operation 406, updates the mapping between the handle provided to the client 302 and the auxiliary processing device, which handle was returned to the client 302 as part of the return from hibernation.

[0027] After waking up from hibernation, the client 302 sends a request to the guest device driver 122 to perform an action with the auxiliary processing device 200 using the existing handle that was restored from hibernation in operation 408. The guest device driver 122 requests, in operation 410, to perform an action with the auxiliary processing device 200 that identified the mapping for the handle.

[0028] 5 is a flow diagram of a method 500 for operating auxiliary processing device 200 in a virtualized environment, according to an example. Although described with respect to the systems of FIGS. 1-4, one skilled in the art will understand that any system configured to perform the steps of method 500 in any technically feasible order is within the scope of the present disclosure.

[0029] In step 502, the guest device driver 122 requests that an action be performed by the auxiliary processing device 200. The guest device driver 122 performs this action in response to a request from the client 302 to have the auxiliary processing device 200 perform the action. The client 302 uses a handle to specify the auxiliary processing device 200 on which to perform the action. The guest device driver 122 stores a mapping that maps the handle to the auxiliary processing device 200. The auxiliary processing device is assigned to the guest VM 204 when the guest VM 204 starts or at another time, for example, by the hypervisor 206. In one example, at initialization time, the guest device driver 122 requests an available auxiliary processing device 200 from the hypervisor 206. The hypervisor 206 selects one of multiple auxiliary processing devices 200 available to the device 100 and sends an identification of the auxiliary processing device 200 to the guest device driver 122. The guest device driver 122 associates the auxiliary processing device 200 with the handle provided by the client 302, so that the guest device driver 122 can send a request identifying the handle to the auxiliary processing device 200 assigned to the virtual machine 204. The auxiliary processing device 200 processes the request in any technically feasible manner.

[0030] In step 504, after hibernation has occurred, during the process of waking from hibernation, guest device driver 122 updates the auxiliary processing device 200 mapped to the handle used by client 302. To perform this update, operating system 120 or another entity notifies guest device driver 122 that waking from hibernation is occurring. In response, guest device driver 122 requests an update of the auxiliary processing device 200 mapped to the handle. Hypervisor 206 provides the updated auxiliary processing device 200 to guest device driver 122, which updates the auxiliary processing device 200 mapped to the handle. The updated auxiliary processing device 200 may be the same auxiliary processing device 200 that was mapped to guest VM 204 before hibernation, or it may be a different auxiliary processing device 200 than the auxiliary processing device 200 that was mapped to guest VM 204 before hibernation.

[0031] Updating the auxiliary processing device assigned to the handle can be performed by guest device driver 122 in any technically feasible manner. In some examples, hypervisor 206 provides updated addressing parameters (e.g., guest physical addresses, virtual functions, physical functions, or other addressing parameters), and guest device driver 122 updates the mapping to point to the new addressing parameters. In some examples, hypervisor 206 updates the mapping between the guest physical addresses that guest device driver 122 mapped to the handle and the system physical addresses so that the system physical addresses point to the newly assigned auxiliary processing device 200. In some examples, if hypervisor 206 provides guest device driver 122 with new physical functions and / or virtual functions, guest device driver 122 updates the mapping to be between the handle used by client 302 and the new physical functions and / or virtual functions.

[0032] In step 506, the guest driver 122 requests that an action be performed using an auxiliary processing device 200 in response to a request by the client 302. The client specifies a handle, and the guest device driver 122 requests that the action be performed using the auxiliary processing device 200 mapped to the handle. The specified handle is the same as the handle specified in step 502. The guest driver may have changed which auxiliary processing device 200 is mapped to that handle, and therefore the guest device driver 122 may provide the request from the client 302 to a different auxiliary processing device 200 than the processing device 200 to which the request was provided in step 502.

[0033] When this specification states that the hypervisor 206 performs an action, this may be interpreted to mean that the host device driver 121 performs the action.

[0034] Elements in the figures may, where appropriate, be embodied as software running on a processor, fixed function processor, programmable processor, or combination thereof. The processor 102, interconnect 112, memory 104, storage 108, various auxiliary devices 106 (including auxiliary processor 114 and IO device 116), auxiliary processing device 200, and client 212 comprise at least some hardware circuitry and, in some embodiments, software running on a processor within that component or another component.

[0035] It should be understood that many variations are possible based on the disclosure herein, and although features and elements are described above in particular combinations, each feature or element can be used alone without other features and elements, or in various combinations, with or without other features and elements.

[0036] The provided methods may be implemented in a general-purpose computer, processor, or processor core. Suitable processors include, by way of example, a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or a state machine. Such processors may be produced by configuring a manufacturing process using the results of processed hardware description language (HDL) instructions and other intermediate data, including netlists (such as instructions that may be stored on a computer-readable medium). The result of such processing may be a mask work, which is used in subsequent semiconductor manufacturing processes to produce a processor embodying features of the present disclosure.

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

Claims

1. 1. A method for performing a processing operation, comprising: requesting that work be performed via a first auxiliary processing device mapped to a handle specified by the first request; updating the handle mapping to reference a second auxiliary processing device upon resuming from hibernation; and requesting, based on the updated mapping, that work be performed via the second auxiliary processing device mapped to the handle specified by the second request. method.

2. Updating the mapping comprises:

10. The method of claim 1, further comprising requesting an updated auxiliary processing device identifier from a hypervisor.

3. the hypervisor selecting the second auxiliary processing device based on usage characteristics of a set of auxiliary processing devices. The method of claim 2.

4. the first request and the second request are received from a client running on a first virtual machine; 10. The method of claim 1.

5. the updating is performed by a device driver running on the first virtual machine. The method of claim 4.

6. hibernation includes saving the state of the virtual machine and powering down the virtual machine. The method of claim 4.

7. Restoring from hibernation includes powering on the virtual machine and restoring the state of the virtual machine. The method of claim 6.

8. the first auxiliary processing device comprises a video encoder engine or a video decoder engine; 10. The method of claim 1.

9. the client generating the first request and the second request includes an application; 10. The method of claim 1.

10. 1. A device for performing processing operations, comprising: a first auxiliary processing device; a second auxiliary processing device; and a processor, The processor: requesting that work be performed via the first auxiliary processing device mapped to the handle specified by the first request; updating the handle mapping to reference the second auxiliary processing device upon resuming from hibernation; requesting, based on the updated mapping, that work be performed via the second auxiliary processing device mapped to the handle specified by the second request; configured to: device.

11. Updating the mapping comprises: requesting an updated identifier of the auxiliary processing device from the hypervisor; The device of claim 10.

12. The processor: configured to select, by the hypervisor, the second auxiliary processing device based on usage characteristics of a set of auxiliary processing devices. The device of claim 11.

13. the first request and the second request are received from a client configured to run on a first virtual machine; The device of claim 10.

14. the updating is performed by a device driver configured to run on the first virtual machine. The device of claim 13.

15. hibernation includes saving the state of the virtual machine and powering down the virtual machine. The device of claim 13.

16. Restoring from hibernation includes powering on the virtual machine and restoring the state of the virtual machine.

16. The device of claim 15.

17. the first auxiliary processing device comprises a video encoder engine or a video decoder engine; The device of claim 10.

18. the client generating the first request and the second request includes an application; The device of claim 10.

19. A computer-readable storage medium storing instructions, comprising: The instructions, when executed by a processor, requesting that work be performed via a first auxiliary processing device mapped to a handle specified by the first request; updating the handle mapping to reference a second auxiliary processing device upon resuming from hibernation; requesting, based on the updated mapping, that work be performed via the second auxiliary processing device mapped to the handle specified by the second request; causing the processor to perform operations including: A computer-readable storage medium.

20. Updating the mapping comprises: requesting an updated identifier of the auxiliary processing device from the hypervisor; 20. The computer-readable storage medium of claim 19.

Images