Transparent provision of virtualization features to unheuristic guest operating system

Abstract

Virtualization features are transparently provided to an unheuristic guest operating system (OS). A guest partition corresponding to the virtual machine is partitioned into a first guest privileged context and a second guest privileged context. The compatibility component executes within a first guest privilege context, while the guest OS executes within a second guest privilege context. The compatibility component is configured to intercept input / output (I / O) operations associated with the guest operation OS. Based on the compatibility component intercepting I / O operations associated with the guest OS, the compatibility component processes the I / O operations using virtualization features that are not supported by the guest OS. Examples of virtualization features include accelerated access to hardware devices and virtual machine guest confidentiality.

Description

Background Art

[0001] Hypervisor-based virtualization technology allocates parts of a computer system's physical resources (e.g., processor cores and / or time, physical memory areas, storage resources) into separate partitions, and executes software in each of these partitions. Therefore, hypervisor-based virtualization technology facilitates the creation of virtual machine (VM) guests, each VM guest executing guest software, such as an operating system (OS) and other software executed therein. Although hypervisor-based virtualization technology can take many forms, many hypervisor-based virtualization technologies use an architecture that includes a hypervisor that directly accesses hardware and operates in an execution environment separate from all other software in the system, a host partition that executes a host OS and a host virtualization stack, and one or more guest partitions corresponding to the VM guest. The host virtualization stack within the host partition manages the guest partition, and therefore the hypervisor grants a higher level of access to the hypervisor and hardware resources to the host partition than the hypervisor grants to the guest partition.

[0002] Taking HYPER-V from MICROSOFT CORPORATION as an example, the HYPER-V hypervisor is the lowest layer of the HYPER-V stack. The HYPER-V hypervisor provides basic functions for scheduling and executing virtual processors for VM guests. The HYPER-V hypervisor has hardware virtualization capabilities (e.g., second-level address translation (SLAT) processor extensions, such as fast virtualization indexes from ADVANCED MICRO DEVICES, or extended page tables from INTEL; input / output (I / O) memory management unit (IOMMU), which connects the I / O bus supporting direct memory access to the main memory; processor virtualization control). The HYPER-V hypervisor also provides (multiple) interfaces to allow the HYPER-V host stack within the host partition to manage VM guests using these virtualization capabilities. The HYPER-V host stack provides common functions for VM guest virtualization (e.g., memory management, VM guest lifecycle management, device virtualization).

[0003] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as described above.Rather, this background is provided merely to illustrate one example technology area where some embodiments described herein may be practiced. Summary of the invention

[0004] In some aspects, the technology described herein relates to a method comprising: intercepting, by a compatibility component within a first guest privileged context of a guest partition, input / output (I / O) operations associated with a guest operating system (OS), the guest OS operating within a second guest privileged context of the guest partition; and processing, by the compatibility component, the I / O operations using virtualization features not supported by the guest OS.

[0005] In some aspects, the technology described herein relates to a computer system comprising: a processing system; and a computer storage medium storing computer executable instructions that can be executed by the processing system to at least: intercept, by a compatibility component within a first guest privileged context of a guest partition, I / O operations associated with a guest OS that operates within a second guest privileged context of the guest partition; and process, by the compatibility component, the I / O operations using virtualization features not supported by the guest OS.

[0006] In some aspects, the technology described herein relates to a computer program product including a computer storage medium storing computer executable instructions that can be executed by a processing system to at least: intercept, by a compatibility component within a first guest privileged context of a guest partition, I / O operations associated with a guest OS that operates within a second guest privileged context of the guest partition; and process, by the compatibility component, the I / O operations using virtualization features not supported by the guest OS.

[0007] This Summary is provided to introduce some concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In order to describe the manner in which the advantages and features of the systems and methods described herein can be obtained, a more particular description of the embodiments briefly described above is presented by reference to specific embodiments illustrated in the accompanying drawings. Understanding that these drawings depict only typical embodiments of the systems and methods described herein and are, therefore, not to be considered limiting of their scope, certain systems and methods are described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0009] Figure 1 An example computer architecture that facilitates transparently providing virtualization features to an unenlightened guest OS is illustrated;

[0010] Figure 2A Shows Figure 1 An example of a virtual machine bus connection within a computer architecture of;

[0011] Figure 2B An example of a heuristic guest OS that exploits virtualization features provided by a host virtualization stack is shown;

[0012] Figure 2C A first example of a compatibility component that transparently provides virtualization features to an unenlightened guest OS is shown;

[0013] Figure 2D A second example of a compatibility component that transparently provides virtualization features to an unenlightened guest OS is shown; and

[0014] Figure 3 A flow chart of an example method for transparently providing virtualization features to an unenlightened guest OS is shown. DETAILED DESCRIPTION

[0015] As hypervisor-based virtualization technologies advance, these hypervisor-based virtualization technologies introduce new features visible to the guest OS and improve guest OS performance, security, etc. As an example, recent hypervisor-based virtualization technologies improve guest OS performance by accelerating access to hardware (e.g., storage, networking), by providing access to new hardware device types (e.g., new storage controller types) to expand the range of hardware available to the guest OS, and by utilizing VM guest confidentiality that isolates VM guest memory and CPU state from the host OS (or even from the hypervisor itself) to improve guest OS security. Since these features are visible to the guest OS, these features currently require the VM guest to operate a "heuristic" guest OS in order to utilize these features. In the description herein, a "heuristic" guest OS refers to a guest OS that recognizes and supports (multiple) specific features provided by hypervisor-based virtualization technologies (e.g., provided by a hypervisor and / or related virtualization stack operating in a host partition). The guest OS may be inspired by the OS vendor (e.g., via modifications to the guest OS's kernel and / or bundled kernel modules / drivers) or by a third party (e.g., by providing third-party kernel modules / drivers). In contrast, in the description herein, an "uninspired" guest OS refers to a guest OS that lacks support for these (multiple) specific features.

[0016] Because the guest OS needs to be enlightened in order to support some virtualization features provided by hypervisor-based virtualization technology, many VM guests may not be able to take advantage of those virtualization features when they become available. For example, due to the lack of appropriate guest OS enlightenment, existing VM guests running at a given VM host may not be able to take advantage of new hardware-based virtualization features (e.g., accelerated hardware access, new hardware device types) when the hardware of the VM host is upgraded, or when the hypervisor stack is upgraded at the VM host, existing VM guests running at a given VM host may not be able to take advantage of new software-based virtualization features (e.g., VM guest confidentiality). Although these existing VM guests may be able to obtain these enlightenments via guest OS updates, those updates may be time-consuming to install, time-consuming to test, disruptive to VM guest workloads (e.g., due to guest OS restarts), and may potentially cause failures or faults (e.g., upgrade failures, incompatibilities). Additionally, a given guest OS may simply not be able to obtain the required heuristics, or may not be able to use these required heuristics (eg, due to regulatory or contractual constraints, due to software compatibility considerations), and thus VM guests operating that guest OS may not be able to take advantage of these new virtualization features.

[0017] Embodiments herein provide an architecture that transparently provides uninspired guest OS access to virtualization features that may normally require guest OS enlightenment. These embodiments introduce a compatibility component into a guest partition that transparently operates "below" the guest OS in the guest partition. The compatibility component intercepts I / O operations associated with the guest OS and processes those I / O operations using virtualization features that the guest OS itself does not support. In one example, the compatibility component provides accelerated hardware access by connecting to a compatible hardware device interface on behalf of the guest OS. In another example, the compatibility component provides access to new hardware device types via hardware protocol conversion, such as converting between commands compatible with a first storage controller type (e.g., integrated drive electronics or IDE) used by the guest OS and commands compatible with a different second storage controller type (e.g., small computer system interface or SCSI) used by the underlying storage device. In yet another example, the compatibility component promotes VM guest confidentiality by managing memory page confidentiality flags, by marshaling I / O payloads between confidential memory and shared memory, and the like. While accelerated hardware access, hardware protocol translation, and VM guest confidentiality are provided as examples, it should be understood that the principles described herein may be applied to a variety of virtualization technologies, both existing and yet to be invented.

[0018] Notably, the embodiments described herein overcome the challenges outlined above. For example, using the compatibility components described herein, existing VM guests can take advantage of new hardware- and / or software-based virtualization features without requiring any modifications to the host OS of those VM guests. This eliminates time-consuming guest OS updates, as well as testing, workload disruptions, and potential failures / failures that may result from those updates. Additionally, this makes new hardware- and / or software-based virtualization features available in situations where it would otherwise not be possible (e.g., the guest OS of a VM guest cannot be updated due to unavailability of an update, regulatory or contractual constraints, software incompatibilities).

[0019] Figure 1 An example computer architecture 100 is shown that facilitates transparently providing virtualization features to an uninitiated guest OS. As shown, the computer architecture 100 includes a computer system 101 that includes hardware 102. Figure 1 In the example of hardware 102, an example of hardware 102 includes processor(s) 103 (e.g., a processor system including a single processor or multiple processors), memory 104 (e.g., system or main memory), storage medium 105 (e.g., a single computer-readable storage medium, or multiple computer-readable storage media), and a network interface 106 (e.g., one or more network interface cards) for interconnecting to one or more other computer systems (via a network). Although not shown, hardware 102 may also include other hardware devices such as an IOMMU, video display interface(s), user input interface(s), a trusted platform module (TPM) for facilitating the provision of a tamper-proof log of loaded boot components, and the like.

[0020] As shown, in computer architecture 100, hypervisor 107 executes directly on hardware 102. In general, hypervisor 107 partitions hardware resources (e.g., processor(s) 103; memory 104; I / O resources such as I / O address space, disk resources, and network resources) among host partition 109 and one or more guest partitions, with host OS 117 executing within host partition 109. In computer architecture 100, hypervisor 107 is shown as having created guest partition 110, in which guest OS 114 executes, and guest partition 111, in which guest OS 115 executes. Figure 1, guest OS 114 is shown as unenlightened (e.g., lacking support for a given virtualization feature), while guest OS 115 is shown as enlightened (e.g., including support for the virtualization feature via enlightenment client 119). In the description herein, the term "VM guest" is used to refer to a "guest partition". In various embodiments, hypervisor 107 also enables supervisory communication between partitions via a virtualization bus. As shown, host OS 117 includes a virtualization stack 118 that manages VM guest virtualization (e.g., memory management, VM guest lifecycle management, device virtualization) via one or more application program interface (API) calls to hypervisor 107.

[0021] In addition to isolating guest partitions from each other, some hypervisor-based virtualization technologies also operate to isolate VM guest states (e.g., registers, memory) from host partitions (and the host OS executed therein), and in some cases also from the hypervisor itself. Many of these technologies can also isolate VM guest states from entities that manage the computing system on which VM guests are hosted. To achieve the foregoing, these virtualization technologies introduce a security boundary at least between the hypervisor 107 and the virtualization stack 118. The security boundary constrains which VM guest resources the host OS 117 (and the virtualization stack 118) can access to ensure the integrity and confidentiality of the VM guest. Such VM guests are referred to herein as confidential VM (CVM) guests. Examples of hardware-based technologies that enable CVM guests include hardware-based technologies, such as software guard extensions (SGX) from INTEL or secure encrypted virtualization secure nested paging (SEV-SNP) from AMD. Software-based CVM guests are also possible.

[0022] In the computer architecture 100, the virtualization stack 118 is capable of dividing the guest partitions into different privileged areas, which are referred to herein as guest privileged contexts. Thus, for example, the guest partition 110 is shown as including a guest privileged context 112 (hereinafter, shown as context 112) and a guest privileged context 113 (hereinafter, shown as context 113). As used herein, privilege means the right to perform security-related functions on a computer system. Therefore, a higher privilege means a greater ability to perform security-related functions on a computer system, while a lower privilege means a lower ability to perform security-related functions on a computer system. In various embodiments, the virtualization stack 118 may divide any of the guest partitions into different guest privileged contexts. As Figure 1As indicated, in some embodiments, context 112 is a lower privileged context (e.g., when compared to context 113), while context 113 is a higher privileged context (e.g., when compared to context 112). In these embodiments, context 112's lower privilege than context 113 means that context 112 cannot access guest partition memory assigned to context 113. In some embodiments, context 113 can access guest partition memory assigned to context 112. In other embodiments, context 113 lacks access to guest partition memory assigned to context 112.

[0023] In some embodiments, context 112 and context 113 are created based on mappings within SLAT 108 (e.g., managed by hypervisor 107), which includes one or more tables that map system physical addresses (SPA) in memory 104 to guest physical addresses (GPA) as seen by guest partition 110. In these embodiments, these mappings prevent context 112 from accessing memory assigned to context 113. In one example, hypervisor 107 is a HYPER-V hypervisor, and virtualization-based security (VBS) is used to subdivide partitions into virtual trust levels (VTLs). In this example, context 112 operates under VBS in a more privileged VTL, while context 113 operates under VBS in a less privileged VTL.

[0024] In other embodiments, context 112 and context 113 are created based on nested virtualization, where guest partition 110 operates a hypervisor similar to hypervisor 107 that partitions the resources of guest partition 110 into sub-partitions. In these embodiments, the hypervisor operating within guest partition 110 prevents context 112 from accessing memory allocated to context 113.

[0025] exist Figure 1, context 113 is shown to include a compatibility component 116. In various embodiments, the compatibility component 116 intercepts I / O operations associated with the guest OS 114 and processes these I / O operations using virtualization feature(s) that the guest OS 114 itself does not support (e.g., virtualization feature(s) for which the guest OS 114 lacks appropriate inspiration). In order to process the I / O operations using virtualization feature(s) for which the guest OS lacks inspiration(s), the compatibility component 116 operates "below" the guest OS 114 within the guest partition. This means that the compatibility component 116 operates in a transparent manner that is independent of any direct collaboration by the guest OS 114. In some embodiments, context 113 operates as a host compatibility layer (HCL) firmware environment that provides services to the guest OS 114 running in context 112. In these embodiments, the compatibility component 116 is part of the HCL firmware environment and provides compatibility services to the guest OS 114.

[0026] Generally speaking, compatibility component 116 is positioned to intercept I / O operations associated with guest OS 114. As previously mentioned, in various embodiments, hypervisor 107 implements supervisory communication between partitions via a virtualized bus, referred to herein as a virtual machine bus (VM bus). In various embodiments, compatibility component 116 intercepts I / O operations associated with guest OS 114 via the VM bus. For demonstration purposes, Figure 2A An example 200a is shown in which computer system 101 also includes multiple VM bus connections (or endpoints). In example 200a, these VM bus connections include a VM bus connection for guest OS 115 (VM bus 201), a VM bus connection for guest OS 114 (VM bus 203), a VM bus connection for compatibility component 116 (VM bus 205), and a VM bus connection for host OS 117 (VM bus 207). In various embodiments, the VM bus includes multiple independent ring buffers (e.g., stored in memory 104), where each ring buffer corresponds to a different VM bus channel. In various embodiments, two entities communicate on the VM bus channel by loading and storing values ​​into the ring buffer corresponding to the channel and signaling the availability of the value via an interrupt.

[0027] Figure 2BExample 200b is shown, which demonstrates the conventional use of the VM bus by the heuristic guest OS to utilize the virtualization features provided by the host virtualization stack. As indicated by the arrow, in example 200b, the heuristic client 119 operating in the guest OS 115 communicates with the virtual service provider (service 206) operating in the virtualization stack 118 to utilize the features (e.g., accelerated hardware access, hardware protocol conversion, VM guest confidentiality) promoted by the service 206. As shown, the communication is completed via the VM bus 201 at the guest OS 115 and the VM bus 207 at the virtualization stack 118. Here, the heuristic client 119 is specifically configured to interact with the service 206 and utilize the virtualization features provided by the service 206, such as accelerated hardware access.

[0028] Figure 2C Example 200c is shown, which demonstrates the first novel use of the VM bus by the compatibility component to transparently provide virtualization features to an uninspired guest OS. As indicated by the arrow, in example 200c, the client 202 communicates via the VM bus 203, which is conventional for the client 202. However, those communications are not routed to the VM bus 207 in the virtualization stack 118, but are consumed by the compatibility component 116 VM bus 205. These communications are then at least partially handled by the virtual service provider (service 204) of the compatibility component 116. In various embodiments, the VM bus 205 intercepts communications targeting the VM bus 207 by being configured to use the same identity information (e.g., VM bus channel, address) as the VM bus 207. In some embodiments, the VM bus 205 is a VM bus server that operates at the context 113 and provides a VM bus channel to the context 112 instead of the channel provided by the VM bus 207.

[0029] Based on the interception of communications sent by the client 202 via the VM bus 203, the service 204 facilitates the use of virtualization features (multiple), such as accelerated hardware access, device access, or VM guest confidentiality for which the client 202 lacks support. In some embodiments, the service 204 implements the heuristics required to utilize the virtualization features on behalf of the guest OS 114. For example, the service 204 can implement at least a portion of the functionality of the heuristic client 119 and interact with the service 206 on behalf of the client 202. In another example, the service 204 can directly provide virtualization features without involving the virtualization stack 118.

[0030] Figure 2DAnother example 200d is shown, which demonstrates a second novel use of the VM bus by the compatibility component to transparently provide virtualization features to uninitiated guest OSes. In example 200d, VM bus 205 receives channels provided from VM bus 207. VM bus 205 then provides these channels to VM bus 203 on behalf of VM bus 207 so that client 202 (e.g., via VM bus 203) can communicate directly with service 206 (e.g., via VM bus 207). Thus, as indicated by the arrows, in example 200d, client 202 communicates via VM bus 203, which is conventional for the client 202. VM bus 205 receives those communications from VM bus 203 and proxies those communications to VM bus 207, where those communications are at least partially handled by service 206. In various embodiments, the VM bus 205 relays control plane messages (e.g., provide channel, create shared memory, delete shared memory, revoke channel) from the VM bus 207 to the VM bus 203. In various embodiments, data plane communications (e.g., SCSI protocol packets) from the service 206 (via the VM bus 207) to the client 202 (via the VM bus 203) occur without interference (e.g., without any conversion) by the compatibility component 116. In some embodiments, these data plane communications are facilitated by shared memory mapped between the virtualization stack 118 and the guest OS 114 and by delivering interrupts directly between the virtualization stack 118 and the guest OS 114. In some embodiments, when the guest partition 110 is created, the VM bus 207 is configured to receive incoming control plane messages using a non-standard port and informs the VM bus 205 of the configuration. The VM bus 205 then acts as a client of the VM bus 207 via the non-standard port and as a server of the VM bus 203 via the standard port to facilitate control plane messages.

[0031] In various embodiments, the techniques of example 200d are combined with the techniques of example 200c. In the example, the virtualization stack 118 presents a SCSI controller and a non-volatile memory express (NVMe) device to the guest OS 114. In this example, the guest OS 114 is not equipped to use NVMe devices, but is equipped to use SCSI devices. To facilitate access to both devices, in this example, the NVMe device is presented to the guest OS 114 using the techniques described in conjunction with example 200c (e.g., with storage protocol conversion performed by the compatibility component 116), while the SCSI device is presented to the guest OS 114 using the techniques described in conjunction with example 200d (e.g., without storage protocol conversion). In some embodiments, the techniques of example 200c are used for services that are not supported by the guest OS 114, while the techniques of example 200d are used for services that are supported by the guest OS 114.

[0032] Regardless of how the VM bus messages are handled, in one example, a service (e.g., service 204 in the environment of example 200c, or service 206 in the environment of example 200d) facilitates use of the accelerated hardware access virtualization feature. Thus, for example, service 206 and / or service 204 can facilitate accelerated communication between client 202 and compatible hardware such as storage media 105 or network interface 106. In these embodiments, client 202 can be a generic paravirtualized storage or network driver that lacks any knowledge or support for hardware acceleration. In one example, service 204 implements driver functionality for communicating with such hardware acceleration (e.g., functionality present in heuristic client 119) and communicates directly (via hypervisor 107) with the hardware or with service 206 (e.g., an accelerated hardware access service provider).

[0033] In another example, a service (e.g., service 204, service 206) facilitates the use of hardware protocols that are not originally supported by the guest OS 114. For example, the guest OS typically includes a natively supported IDE-based storage controller. However, many VM hosts now typically utilize SCSI storage controllers. Additionally, many hypervisors utilize virtualized SCSI storage controllers to present virtual (e.g., file backup) disk images to VM guests. In either case, an uninspired guest OS cannot access any storage device (real or virtual) presented by the hypervisor 107 using a SCSI storage controller. In various embodiments, a service (e.g., service 204) converts between IDE-based commands used by the guest OS 114 and SCSI-based commands used by the underlying storage controller (whether a physical controller or a virtualized controller). This means that for an uninspired guest OS, the storage device appears to be IDE-based, and the uninspired guest OS can use IDE commands to interact with the storage device. In some embodiments, service 204 receives IDE-based commands issued by guest OS 114 and intercepted by VM bus 205, converts those commands into equivalent SCSI-based commands, and forwards the converted commands to an underlying storage controller (e.g., a physical controller, a virtual controller). Additionally, in these embodiments, service 204 receives SCSI-based commands issued by a storage controller, converts those commands into equivalent IDE-based commands, and forwards the converted commands to guest OS 114 via VM bus 205.

[0034] In yet another example, a service (e.g., service 204, service 206) facilitates the use of VM guest confidentiality virtualization features (such as by using INTEL SGX, AMD SEV-SNP, or software-based mechanisms). Conventionally, a guest OS requires kernel heuristics to operate within a CVM guest. Examples include memory manager heuristics to manage confidentiality flags (e.g., C bits) for memory spaces used for CVM guests and to manage which memory pages are confidential (e.g., encrypted) or shared (e.g., shared with the host OS) to the CVM guest. In various embodiments, even in the absence of such heuristics for the guest OS 114, the service (e.g., service 204, service 206) enables the VM guest to operate as a CVM guest. In these embodiments, the service may implement memory manager heuristics (e.g., for managing memory page confidentiality flags), exception handlers, and / or data marshaling functionality. For example, in various embodiments, the service 204 (and / or the service 206) manages confidentiality flags to designate portion(s) of the memory of the guest partition 110 as shared (e.g., shared with the host partition 109), and to designate other portion(s) of the memory of the guest partition 110 as confidential to the guest partition 110. In various embodiments, the service 204 (and / or the service 206) also marshals data payloads of I / O operations originating from the client 202 from confidential memory to shared memory, and marshals data payloads of I / O operations originating from the host OS 117 from shared memory to confidential memory.

[0035] It is worth noting that in various embodiments, various service functions can be combined. For example, service 204 (or multiple services operating at compatibility component 116) can provide each or a subset of accelerated hardware access, hardware protocol conversion, and VM guest confidentiality. In another example, service 206 (or multiple services operating at virtualization stack 118) can provide each or a subset of accelerated hardware access, hardware protocol conversion, and VM guest confidentiality. In yet another example, the service functionality is provided by a combination of services at compatibility component 116 and virtualization stack 118.

[0036] Now, combined with Figure 3 The operation of the compatibility component 116 is described, which shows a flowchart of an example method 300 for transparently providing virtualization features to an unenlightened guest OS. In various embodiments, instructions for implementing the method 300 are encoded as computer executable instructions (e.g., the compatibility component 116) stored on a computer storage medium (e.g., the storage medium 105), which can be executed by a processor system (e.g., (multiple) processors 103) to cause the computer system (e.g., the computer system 101) to perform the method 300.

[0037] The following discussion now refers to some methods and method actions. Although method actions may be discussed in certain orders or may be shown in flowcharts as occurring in a particular order, no particular order is required unless otherwise stated or because an action depends on another action being completed before the action is performed.

[0038] refer to Figure 3 In various embodiments, method 300 includes an action 301 of creating a privileged memory context and a non-privileged memory context of a guest partition. In some embodiments, action 301 includes creating a first guest privileged context and a second guest privileged context of the guest partition. In various embodiments, the second guest privileged context is restricted from accessing the memory associated with the first guest privileged context. In some embodiments of action 301, these contexts are created based on SLAT. In other embodiments of action 301, these contexts are created based on nested virtualization. For example, the virtualization stack 118 partitions the guest partition 110 into context 112 and context 113, wherein context 112 is restricted from accessing the memory associated with context 113. This enables the compatibility component 116 to operate within a context 113 that is separate from the guest OS 114 (its operating context 112). In various embodiments, this means that the compatibility component 116 operates in a manner that is transparent to the guest OS 114.

[0039] Method 300 also includes an action 302 of configuring a compatibility component within a privileged memory context to intercept I / O operations of a guest OS. In some embodiments, action 302 includes instantiating a compatibility component within a first guest privileged context of a guest partition. For example, in conjunction with booting a VM guest corresponding to guest partition 110, compatibility component 116 is instantiated within context 113. In various embodiments, compatibility component 116 is part of an HCL that is booted before guest OS 114 within boot context 112. This has the effect of enabling compatibility component 116 to operate within a guest partition in a manner separate from a guest OS also executing within a guest partition. In various embodiments, instantiating a compatibility component includes configuring the compatibility component to intercept I / O operations associated with a guest OS that operates within a second guest privileged context of a guest partition. For example, compatibility component 116 is configured to intercept I / O operations of guest OS 114. This has the effect of enabling compatibility component 116 to operate on these I / O operations in a manner that is transparent to guest OS 114.

[0040] In some embodiments, action 302 includes an action 303 of configuring a virtual bus connection. In various embodiments, action 303 includes configuring a first virtualized bus connection within a first guest privileged context to interface with a second virtualized bus connection within a second guest privileged context. For example, the HCL configures VM bus 205 to intercept I / O operations sent through VM bus 203, such as by configuring VM bus 205 using the same VM bus channel, address, etc. used by VM bus 207. In one embodiment, VM bus 205 is a VM bus server that provides the VM bus channel (rather than providing the VM bus channel at VM bus 207, which may be conventional). This has the effect that VM bus 205 receives I / O operations sent by guest OS 114 through VM bus 203. Additionally, in various embodiments, configuring the compatibility component to intercept I / O operations associated with the guest OS in action 302 includes configuring the compatibility component to listen for I / O operations at the first virtualized bus connection. For example, compatibility component 116 is configured to listen at VM bus 205.

[0041] In some embodiments, action 302 includes action 304 of instantiating a virtual service provider. In some embodiments, action 304 includes instantiating a virtual service provider that facilitates use of virtualization features not supported by the guest OS. For example, compatibility component 116 instantiates service 204 that implements the heuristics needed to utilize virtualization features (e.g., provided by hypervisor 107 or virtualization stack 118) on behalf of guest OS 114. The effect is to add functionality for using virtualization features for which guest OS 114 does not have heuristics to software executing within the same partition as guest OS 114, but in a manner transparent to guest OS 114.

[0042] Method 300 also includes an act 305 of intercepting I / O operations of the guest OS at the compatibility component. For example, compatibility component 116 uses VM bus 205 to intercept I / O operations from guest OS 114.

[0043] Method 300 also includes an action 306 of processing the I / O operation at the compatibility component using a virtualization feature not supported by the guest OS. In some embodiments, action 306 includes intercepting the I / O operation associated with the guest OS based on the compatibility component, and the compatibility component uses the virtualization feature not supported by the guest OS to process the I / O operation. For example, service 204 (and / or service 206) facilitates the use of the virtualization feature not supported by the guest OS 114 as part of processing the I / O operation of the guest OS 114 intercepted in action 305. The effect is to utilize the virtualization feature not supported by the guest OS 114 in a manner that is transparent to the guest OS 114.

[0044] In some embodiments, action 306 includes action 307 of providing accelerated hardware access. Thus, in some embodiments, the virtualization feature is accelerated access to a hardware device. For example, service 204 (and / or service 206) facilitates accelerated hardware access by facilitating accelerated communication between client 202 and compatible hardware. In some embodiments, service 204 (and / or service 206) implements driver functionality for accelerating communication with such hardware and communicates directly (via hypervisor 107) with the hardware. In other embodiments, service 204 communicates with service 206 (e.g., an accelerated hardware access service provider). Thus, in some embodiments, processing an I / O operation includes processing an I / O operation using a virtual service provider for a hardware device, which is executed within a first guest privileged context.

[0045] In some embodiments, action 306 includes an action 308 of providing hardware protocol conversion. Thus, in some embodiments, the virtualization feature provides access to the device via hardware protocol conversion. For example, service 204 (and / or service 206) performs hardware protocol conversion by receiving commands issued by guest OS 114 using a first protocol (e.g., IDE), converting those commands into equivalent commands in a second protocol (e.g., SCSI), and forwarding the converted commands to the underlying physical or virtualized device (e.g., storage controller). Additionally, service 204 (and / or service 206) receives commands in a second protocol issued by an underlying physical or virtualized device, converts those commands into equivalent commands in the first protocol, and forwards the converted commands to guest OS 114 via VM bus 205.

[0046] In some embodiments, action 306 includes action 309 of providing VM guest confidentiality. Thus, in some embodiments, the virtualization feature is VM guest confidentiality. For example, service 204 (and / or service 206) facilitates the use of VM guest confidentiality virtualization features (such as by using INTEL SGX, AMD SEV-SNP, or software-based mechanisms). In various embodiments, service 204 (and / or service 206) implements memory manager heuristics, such as for managing memory page confidentiality flags. Thus, in some embodiments, processing I / O operations includes managing page visibility flags for memory pages that are used to store payloads of I / O operations. In various embodiments, service 204 (and / or service 206) implements an exception handler. Thus, in some embodiments, processing I / O operations includes handling hardware-triggered exceptions associated with I / O operations. In some embodiments, service 204 (and / or service 206) implements data marshaling between confidential memory and shared memory. Thus, in some embodiments, processing an I / O operation includes copying the payload of the I / O operation from a guest-private memory page to a host-visible memory page; or copying the payload of the I / O operation from a host-visible memory page to a guest-private memory page.

[0047] The ellipsis within action 306 indicates that compatibility component 116 may support a variety of virtualization features beyond those demonstrated in actions 307, 308, and 309. Therefore, compatibility component 116 and method 300 may be applied to a variety of virtualization technologies, both existing and yet to be invented.

[0048] Embodiments of the present disclosure may include or utilize a special-purpose computer system or a general-purpose computer system (e.g., computer system 101) that includes computer hardware, such as a processor system (e.g., (multiple) processors 103) and a system memory (e.g., memory 104) as discussed in more detail below. Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general-purpose computer system or a special-purpose computer system. Computer-readable media that store computer-executable instructions and / or data structures are computer storage media (e.g., storage media 105). Computer-readable media that carry computer-executable instructions and / or data structures are transmission media. Therefore, by way of example, embodiments of the present disclosure may include at least two distinct types of computer-readable media: computer storage media and transmission media.

[0049] Computer storage media are physical storage media that store computer executable instructions and / or data structures. Physical storage media include computer hardware, such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), solid-state drive (SSD), flash memory, phase change memory (PCM), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other (multiple) hardware storage devices that can be used to store program code in the form of computer executable instructions or data structures, which can be accessed and executed by general-purpose computer systems or special-purpose computer systems to implement the disclosed functions.

[0050] Transmission medium can comprise network and / or data link, and this network and / or data link can be used to carry the program code of computer executable instruction or data structure form, and can be visited by general-purpose computer system or special-purpose computer system." network " is defined as one or more data links that can transmit electronic data between computer system and / or module and / or other electronic equipment.When transmitting or providing information to computer system by network or another communication connection (hard-wired, wireless or hard-wired or wireless combination), computer system can regard this connection as transmission medium.Above-mentioned combination also should be included in the scope of computer-readable medium.

[0051] In addition, upon reaching various computer system components, program code in the form of computer executable instructions or data structures can be automatically transferred from transmission media to computer storage media (or vice versa). For example, computer executable instructions or data structures received over a network or data link can be cached in RAM within a network interface module (e.g., network interface 106) and ultimately transferred to computer system RAM and / or less volatile computer storage media at the computer system. Therefore, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.

[0052] Computer executable instructions include, for example, instructions and data that, when executed at one or more processors, cause a general purpose computer system, a special purpose computer system, or a special purpose processing device to perform a specific function or group of functions. For example, computer executable instructions may be binary code, intermediate format instructions such as assembly language, or even source code.

[0053] It should be understood that the disclosed system and method can be practiced in a network computing environment with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablet computers, pagers, routers, switches, etc. The various embodiments of the present disclosure can also be practiced in a distributed system environment, where a local computer system and a remote computer system that are linked (by a hardwired data link, a wireless data link, or by a combination of a hardwired data link and a wireless data link) through a network both perform tasks. Thus, in a distributed system environment, a computer system can include multiple component computer systems. In a distributed system environment, a program module can be located in a local memory storage device and a remote memory storage device.

[0054] It should also be understood that embodiments of the present disclosure may be practiced in a cloud computing environment. A cloud computing environment may be distributed, although this is not required. When distributed, a cloud computing environment may be internationally distributed within an organization and / or have components owned across multiple organizations. In this specification and the appended claims, "cloud computing" is defined as a model for implementing on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage devices, applications, and services). A cloud computing model may consist of various features (such as on-demand self-service, extensive network access, resource pooling, rapid elasticity, measured services, etc.). A cloud computing model may also appear in the form of various service models (such as software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS)). Cloud computing models may also be deployed using different deployment models such as private clouds, community clouds, public clouds, hybrid clouds, etc.

[0055] Some embodiments (such as cloud computing environments) may include a system that includes one or more hosts, each of which is capable of running one or more virtual machines. During operation, the virtual machine emulates an operating computing system that supports an operating system and may also support one or more other applications. In some embodiments, each host includes a hypervisor that uses physical resources extracted from the virtual machine's view to emulate the virtual resources of the virtual machine. The hypervisor also provides appropriate isolation between virtual machines. Therefore, from the perspective of any given virtual machine, even if the virtual machine is only interfaced with the appearance of physical resources (e.g., virtual resources), the hypervisor also provides the illusion that the virtual machine is being interfaced with the physical resources. Examples of physical resources include processing power, memory, disk space, network bandwidth, media drives, etc.

[0056] Although the subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or acts described above, or to the order of the acts described above. Instead, the described features and acts are disclosed as example forms of implementing the claims.

[0057] The present disclosure may be embodied in other specific forms without departing from its essential characteristics. The described embodiments are considered in all respects to be illustrative and not restrictive. All changes within the meaning and range of equivalents of the claims are included within their scope.

[0058] When introducing elements in the appended claims, the articles "a," "an," "the," and "said" are intended to mean that there are one or more of the elements. The terms "comprising," "including," and "having" are intended to be inclusive and mean that there may be additional elements other than the listed elements.

Claims

1. A method comprising: intercepting, by a compatibility component within a first guest privileged context of a guest partition, input / output (I / O) operations associated with a guest operating system (OS) operating within a second guest privileged context of the guest partition; and The I / O operation is processed by the compatibility component using a virtualization feature not supported by the guest OS. 2 . The method of claim 1 , wherein the second guest privileged context is restricted from accessing memory associated with the first guest privileged context. The method of claim 1 , wherein the virtualization feature is accelerated access to hardware devices. 4 . The method of claim 3 , wherein processing the I / O operation comprises processing the I / O operation using a virtual service provider for the hardware device, the virtual service provider executing within the first guest privileged context. The method of claim 1 , wherein the virtualization feature provides access to a device via hardware protocol translation. The method of claim 1 , wherein the virtualization feature is virtual machine guest confidentiality. 7 . The method of claim 6 , wherein processing the I / O operation comprises managing a page visibility flag for a memory page used to store a payload of the I / O operation.

8. The method of claim 6, wherein processing the I / O operation comprises copying a payload of the I / O operation from a guest-private memory page to a host-visible memory page.

9. The method of claim 6, wherein processing the I / O operation comprises copying a payload of the I / O operation from a host-visible memory page to a guest-private memory page.

10. The method of claim 6, wherein processing the I / O operation comprises handling a hardware-triggered exception associated with the I / O operation.

11. The method of claim 1 , further comprising configuring a first virtualized bus connection within the first guest privileged context to interface with a second virtualized bus connection within the second guest privileged context.

12. The method of claim 11, further comprising configuring the compatibility component to intercept I / O operations associated with the guest OS, including configuring the compatibility component to listen to I / O operations at the first virtualized bus connection.

13. A computer system comprising: Processing systems; as well as A computer storage medium storing computer executable instructions executable by the processing system to at least: instantiating a compatibility component within a first guest privileged context of a guest partition, including configuring the compatibility component to intercept input / output (I / O) operations associated with a guest operating system (OS) operating within a second guest privileged context of the guest partition; and Based on the compatibility component intercepting the I / O operation associated with the guest OS, the compatibility component processes the I / O operation using a virtualization feature that is not supported by the guest OS.

14. The computer system of claim 13, wherein configuring the compatibility component to intercept I / O operations associated with the guest OS comprises configuring the compatibility component to listen to I / O operations at a first virtualized bus connection within the first guest privileged context, the first virtualized bus connection interfacing with a second virtualized bus connection within the second guest privileged context.

15. The computer system of claim 13, wherein the virtualization feature is accelerated access to a hardware device, and wherein processing the I / O operation comprises processing the I / O operation using a virtual service provider for the hardware device, the virtual service provider executing within the first guest privileged context.

Images