Patent Description:
In accordance with one or more aspects, in a host of a computing device, a physical device to be made accessible to a guest partition of the computing device is identified. A first portion of the physical device is virtualized for access to the physical device by the guest partition, the first portion including at least part of a control plane for the physical device. Access to the first portion of the physical device are managed by the guest partition. The guest partition is allowed to directly access a second portion of the physical device, the second portion including at least part of a data plane for the physical device.

Entities represented in the figures may be indicative of one or more entities and thus reference may be made interchangeably to single or plural forms of the entities in the discussion.

Managing guest partition access to physical devices is discussed herein. A computing device includes one or more guest partitions and a host. Each guest partition is isolated from other guest partitions, providing security by preventing programs running in one guest partition from accessing memory or programs in other guest partitions. A host in the computing device manages the guest partitions, including the creation of guest partitions.

The computing device also includes one or more physical devices. A physical device can be virtualized, at least in part, by the host and made available to the guest partitions. This allows each guest partition to access its own version of the physical device.

A physical device includes both a control plane and a data plane. The control plane refers to the manner in which programs interact with the physical device to configure or control the physical device, such as gathering information about the physical device, setting control or configuration values for the physical device, and so forth. Different memory addresses or address ranges can be associated with the control plane. The data plane refers to the manner in which the programs use the physical device, sending data to and/or receiving data from the physical device. Different memory addresses or address ranges can be associated with the data plane. It should be noted that the data plane and the control plane need not be physical constructs, and can be interleaved and all part of the same region of memory. For example, control planes can contain data locations and data planes can contain control locations.

Using the techniques discussed herein, the host provides direct access to at least part of the data plane of a physical device to a guest partition. This direct access allows programs running in the guest partition to directly write to and/or read from the physical device. The host need not virtualize the part of the data plane for which direct access is provided, increasing the speed with which a program in the guest partition can access that part of the data plane because no time or computation effort need be expended in virtualizing that part of the data plane.

However, the host does virtualize at least some of the control plane of the physical device. This virtualizing refers to the host exposing at least some of a control plane for the physical device to the guest partition that is not the actual control plane of the physical device. Requests to access (e.g., read, write, modify, etc.) the exposed control plane of the physical device are received by the host from the guest partition, and converted as appropriate to the control plane for the physical device. Thus, the guest partition does not have direct access to at least some of the control plane for the physical device.

The techniques discussed herein improve security of the computing device by restricting access to the control plane of the physical device by the guest partitions. The techniques further improve performance of the computing device by allowing the guest partitions to directly access the data plane of the physical device. Thus, programs running in the guest partition can directly (and thus quickly) send data to and/or receive data from the physical device on the data plane of the physical device, but are prevented from directly accessing the control plane of the physical device (and thus potentially interfering with the operation of the physical device).

<FIG> is a block diagram illustrating an example computing device <NUM> implementing the managing guest partition access to physical devices in accordance with one or more embodiments. Computing device <NUM> can be a variety of different types of devices, such as a desktop computer, a server computer, a laptop or netbook computer, a mobile device (e.g., a tablet or phablet device, a cellular or other wireless phone (e.g., a smartphone), a notepad computer, a mobile station), a wearable device (e.g., eyeglasses, head-mounted display, watch, bracelet, augmented reality (AR) devices, virtual reality (VR) devices), an entertainment device (e.g., an entertainment appliance, a set-top box communicatively coupled to a display device, a game console), Internet of Things (IoT) devices (e.g., objects or things with software, firmware, and/or hardware to allow communication with other devices), a television or other display device, an automotive computer, and so forth. Thus, computing device <NUM> may range from a full resource device with substantial memory and processor resources (e.g., personal computers, game consoles) to a low-resource device with limited memory and/or processing resources (e.g., traditional set-top boxes, hand-held game consoles).

Computing device <NUM> includes a host <NUM>, one or more (x) guest partitions <NUM>(<NUM>),. , <NUM>(x), and one or more (y) physical devices <NUM>(<NUM>),. , <NUM>(y). Each guest partition <NUM> refers to an isolated session that includes one or more components. These components include, for example, virtual devices (e.g., one or more processors, memory, storage devices), a base operating system (e.g., an operating system kernel), a user-mode environment, applications, and so forth. A base operating system component provides various different low level system services to components in the guest, such as session management, program execution, input/output services, resource allocation, and so forth. The base operating system component can be a full operating system, or alternatively only a portion of a full operating system (e.g., the base operating system component may be a very small component if the guest shares most of the operating system with the host (in particular, the kernel)). The user-mode environment component provides a runtime environment for applications in the guest (e.g., a Java Runtime Environment, a. NET framework, and so forth). The application component is an application that is desired (e.g., by a user, administrator, other program, etc.) to be run in the guest (e.g., a web service, a calculation engine, etc.).

One type of partition that a guest partition <NUM> can be implemented as is referred to as a process container. For a process container, the application processes within the guest run as if they were operating on their own individual system (e.g., computing device), which is accomplished using namespace isolation. The host <NUM> implements namespace isolation. Namespace isolation provides processes in a guest partition a composed view consisting of the shared parts of the host <NUM> and the isolated parts of the host that are specific to each container such as filesystem, configuration, network, and so forth.

Another type of guest that a guest partition <NUM> can be implemented as is referred to as a virtualized container. For a virtualized container, the virtualized container is run in a lightweight virtual machine that, rather than having specific physical memory of the computing device <NUM> assigned to the virtual machine, has virtual address backed memory pages. Thus, the memory pages assigned to the virtual machine can be swapped out to a page file. The use of a lightweight virtual machine provides additional security and isolation between processes running in a guest. Thus, whereas process containers use process isolation or silo-based process isolation to achieve their containment, virtualized containers use virtual machine based protection to achieve a higher level of isolation beyond what a normal process boundary can provide. A guest partition <NUM> may also be run in a virtual machine using physical memory of the computing device <NUM>, and the techniques discussed herein used with the virtual machine. Such a virtual machine using physical memory allows for higher isolation, e.g., in situations where the use of virtual memory for the virtual machine is not desired because of performance or security concerns.

The host <NUM> includes a guest partition manager <NUM>, a control plane interface <NUM>, and optionally a data plane interface <NUM>. The host <NUM> also manages one or more containers or virtual machines, illustrated as guest partitions <NUM>. The guest partition manager <NUM> creates a guest partition in any of a variety of manners, such as building or generating a guest partition from scratch, by "cloning" a guest partition template (which refers to copying the guest partition template into memory of the computing device <NUM> to create a new guest partition <NUM>), and so forth. While the newly created guest partition <NUM> is running, the host <NUM> manages the guest partition <NUM>, for example determining when the guest partition <NUM> is to run (i.e., execute). The guest partition manager <NUM> also manages tear down or deletion of the guest partition <NUM> when the guest partition <NUM> is no longer needed or desired in the computing device <NUM>.

The host <NUM> can be implemented in a variety of different manners. In one or more embodiments, the host <NUM> is implemented as a hypervisor. Additionally or alternatively, the host <NUM> is implemented as a host operating system (e.g., the host <NUM> can be implemented as a partition referred to as a host partition).

Each physical device <NUM> is a hardware device that is at least partially virtualized to the guest partitions <NUM>. Although illustrated as part of the computing device <NUM>, a physical device <NUM> can alternatively be separate from but coupled to the computing device <NUM>. Physical devices <NUM> can be any of a variety of different types of devices that a program running in a guest partition <NUM> can communicate data to and/or receive data from. Examples of physical devices <NUM> include network interface cards, storage controllers, printers, graphics processors or chips, field-programmable gate arrays (FPGAs), and so forth.

In one or more embodiments, the physical devices <NUM> are memory mapped input/output (I/O) devices. A memory mapped I/O device refers to a device that includes one or more regions (e.g., memory, registers, etc.) that are associated with (also referred to as mapped to) physical memory of the computing device <NUM>. A program running on the computing device <NUM> can access the one or more regions of the physical device <NUM> by accessing the physical memory of the computing device <NUM> associated with those one or more regions. For example, the physical device <NUM> can monitor an address bus of the computing device <NUM> and respond to any requests (e.g., return data that is requested to be read, store data that is requested to be written) targeting addresses in those one or more regions.

Each physical device <NUM> includes both a control plane and a data plane. The control plane refers to the manner in which programs running on the computing device <NUM> (including programs running in the guest partitions <NUM>) interact with the physical device <NUM> to control the physical device <NUM>, such as gathering information about the physical device <NUM>, setting control or configuration values for the physical device <NUM>, and so forth. In one or more embodiments, the control plane is included in the one or more regions that are associated with (also referred to as mapped to) physical memory of the computing device <NUM>.

The data plane refers to the manner in which the programs running on the computing device <NUM> (including programs running in the guest partitions <NUM>) use the physical device <NUM>. This use of the physical device <NUM> includes sending data to the physical device <NUM> (e.g., writing data to the physical device <NUM>) and/or receiving data from (e.g., reading data from the physical device <NUM>). In one or more embodiments, the data plane is included in the one or more regions that are associated with (also referred to as mapped to) physical memory of the computing device <NUM>.

Using the techniques discussed herein, the host <NUM> virtualizes at least part of the control plane of a physical device <NUM>. Control planes of all physical devices <NUM> can be virtualized, or alternatively control planes of only some of the physical devices <NUM> can be virtualized. This virtualizing refers to the host <NUM> exposing a control plane for the physical device <NUM> to the guest partition <NUM> that is not the actual control plane of the physical device <NUM>. The control plane interface <NUM> manages exposing a control plane for the physical device <NUM> to the guest partition <NUM>, and managing access requests for the control plane received from the guest partition <NUM> (including programs running in the guest partition <NUM>). Requests to access (e.g., read, write, modify, etc.) the control plane of the physical device <NUM> are received by the control plane interface <NUM> from the guest partition <NUM> and converted as appropriate to the control plane for the physical device. This conversion can be performed in various manners, as discussed in more detail below. Thus, the guest partition <NUM> does not have direct access to at least part of the control plane for the physical device <NUM>.

The host <NUM> optionally allows direct access to at least part of the control plane of a physical device <NUM> to a guest partition <NUM>. This direct access allows the guest partition <NUM> (and programs running in the guest partition <NUM>) to directly write to and/or read from the physical device <NUM>. Direct access to at least part of the control planes of all physical devices <NUM> can be allowed, or alternatively direct access to at least part of the control planes of only some of the physical devices <NUM> can be allowed. Thus the host <NUM> can allow direct access by a guest partition <NUM> to all of the physical device control plane <NUM>, to only part of the physical device control plane <NUM>, or to none of the physical device control plane <NUM>. Parts (some or all) of the physical device control plane <NUM> for which direct access is not available to the guest partition <NUM> can be virtualized.

Similarly, the host <NUM> allows direct access to at least part of the data plane of a physical device <NUM> to a guest partition <NUM>. This direct access allows the guest partition <NUM> (and programs running in the guest partition <NUM>) to directly write to and/or read from the physical device <NUM>. Direct access to at least part of the data planes of all physical devices <NUM> can be allowed, or alternatively direct access to at least part of the data planes of only some of the physical devices <NUM> can be allowed. Thus the host <NUM> can allow direct access by a guest partition <NUM> to all of the physical device data plane <NUM>, to only part of the physical device data plane <NUM>, or to none of the physical device data plane <NUM>. Parts (some or all) of the physical device control data plane 206for which direct access is not available to the guest partition <NUM> can be virtualized.

The host <NUM> optionally virtualizes part of the data plane of at least one physical device <NUM>. Parts of data planes of all physical devices <NUM> can be virtualized, or alternatively parts of data planes of only some of the physical devices <NUM> can be virtualized. This virtualizing refers to the host <NUM> exposing part of a data plane for the physical device <NUM> to the guest partition <NUM> that is not the actual part of the data plane of the physical device <NUM>. The data plane interface <NUM> manages exposing part of a data plane for the physical device <NUM> to the guest partition <NUM>, and manages access requests for the part of the data plane received from the guest partition <NUM> (including programs running in the guest partition <NUM>). Requests to access (e.g., read, write, modify, etc.) the part of the data plane of the physical device <NUM> are received by the data plane interface <NUM> from the guest partition <NUM> and converted as appropriate to the data plane for the physical device. This conversion can be performed in various manners, as discussed in more detail below.

<FIG> is a block diagram illustrating an example of guest partition access to a physical device in accordance with one or more embodiments. The example of <FIG> includes a guest partition <NUM>, a physical device control plane <NUM>, and a physical device data plane <NUM>. The guest partition <NUM> can be any of the guest partitions <NUM> of <FIG>. The physical device control plane <NUM> is a control plane of, and the physical device data plane <NUM> is a data plane of, a physical device <NUM> of <FIG>. The example of <FIG> also includes a control plane interface <NUM> and a data plane interface <NUM>.

The guest partition <NUM> can directly access at least part of the physical device data plane <NUM>, illustrated by arrow <NUM>. It should be noted that references herein to the guest partition <NUM> directly accessing part of a physical device data plane <NUM> include programs running in the guest partition <NUM> directly accessing part of the physical device data plane. Optionally, the guest partition <NUM> can directly access at least part of the physical device control plane <NUM>, illustrated by arrow <NUM>. It should be noted that references herein to the guest partition <NUM> directly accessing part of a physical device control plane <NUM> include programs running in the guest partition <NUM> directly accessing part of the physical device data plane.

Direct access by a guest partition to a physical device makes the physical device visible to the guest partition. Direct access by the guest partition <NUM> to at least part of the physical device data plane <NUM> and/or physical device control plane <NUM> can be accomplished in a variety of different manners. In one or more embodiments, the computing device <NUM> implementing the guest partition <NUM>, control plane interface <NUM>, and data plane interface <NUM> includes a processor that supports direct access to the physical device by a guest partition. For example, the computing device <NUM> can include a processor that supports Intel® Virtualization Technology for Directed I/O (VT-d) technology, which provides direct access to the physical device by a guest partition.

The control plane interface <NUM> includes a control module <NUM> and an exposed physical device control plane <NUM>. In one or more embodiments, at least part of the physical device control plane <NUM> is virtualized by the control plane interface <NUM> making an exposed physical device control plane <NUM> accessible to the guest partition <NUM>. The exposed physical device control plane <NUM> appears to the guest partition <NUM> as if it were the physical device control plane <NUM>, and the guest partition <NUM> need not be aware (and typically is not aware) that the exposed physical device control plane <NUM> is not actually the physical device control plane <NUM>.

Access requests (e.g., read and/or write requests) to the exposed physical device control plane <NUM> by the guest partition <NUM> are analyzed by the control module <NUM> and handled appropriately. The access requests can be analyzed and handled in a variety of different manners. In one or more embodiments, the control module <NUM> maintains a mapping of addresses in the exposed physical device control plane <NUM> to addresses in the physical device control plane <NUM>. The control module <NUM> uses this mapping to translate addresses in address requests received from the guest partition <NUM> to the appropriate address for the physical device control plane <NUM>.

In one or more embodiments, the control module <NUM> also applies one or more rules, criteria, and/or algorithms to access requests received from the guest partition <NUM> to determine whether to allow those access requests to be applied to the physical device control plane <NUM>. These rules, criteria, and/or algorithms can take into account various factors, such as the address of the access request, the program making the request, the physical device, and so forth. For example, the control module <NUM> can apply one or more rules specifying that one particular program cannot access the physical device control plane <NUM> but other programs can access the control plane <NUM>.

It should be noted that all of the physical device control plane <NUM> need not be mapped to the exposed physical device control plane <NUM>. The control plane interface <NUM> can determine that part of the physical device control plane <NUM> is not to be accessible to the guest partition <NUM>, and exclude that part of the physical device control plane <NUM> from the exposed physical device control plane <NUM>. The control plane interface <NUM> can determine which parts of the physical device control plane <NUM> are not to be accessible to the guest partition <NUM> in a variety of different manners, such as being pre-configured with an indication of which parts of the physical device control plane <NUM> are not to be accessible to the guest partition <NUM>, obtaining an indication of which parts of the physical device control plane <NUM> are not to be accessible to the guest partition <NUM> from a remote service (e.g., a service associated with the manufacturer of the physical device, the manufacturer of the computing device <NUM>, and so forth).

As an example, the physical device control plane <NUM> can be made up of four pages of memory (e.g., four <NUM> kilobyte blocks of memory). Although examples are discussed herein with references to pages of memory, it should be noted that the techniques discussed herein can be applied to any blocks, regions, chunks, etc. of memory. The control plane interface <NUM> may determine that pages <NUM>, <NUM>, and <NUM> of the physical device control plane <NUM> contain information that is to be accessible to the guest partition <NUM>, but page <NUM> of the physical device control plane <NUM> contains information that is not to be accessible to the guest partition <NUM>. In this situation, the exposed physical device control plane <NUM> includes three pages that are mapped to pages <NUM>, <NUM>, and <NUM> of the physical device control plane <NUM>, but no page that is mapped to page <NUM> of the physical device control plane <NUM>. Thus, rather than simply ignoring or not mapping access requests to an address that is not to be accessible to the guest partition <NUM>, the exposed physical device control plane <NUM> can simply include no address that maps to the address that is not to be accessible to the guest partition <NUM>.

It should also be noted that pages of memory in the exposed physical device control plane <NUM> can be mapped to pages of the physical device control plane <NUM> in a non-sequential order. The order in which the pages of memory in the exposed physical device control plane <NUM> are mapped to pages of the physical device control plane <NUM> can be determined in a variety of different manners, such as being pre-configured in the control plane interface <NUM>, being obtained from a remote service (e.g., a service associated with the manufacturer of the physical device, the manufacturer of the computing device <NUM>, etc.), and so forth.

For example, the physical device control plane <NUM> may include memory pages <NUM>, <NUM>, <NUM>, and <NUM>. The exposed physical device control plane <NUM>, however, may map those memory pages into memory pages <NUM>, <NUM>, <NUM>, and <NUM>, respectively. By way of another example, the physical device control plane <NUM> may include memory pages <NUM>, <NUM>, and <NUM>. The exposed physical device control plane <NUM>, however, may map those memory pages into memory pages <NUM>, <NUM>, and <NUM>, respectively.

Which parts of the physical device control plane <NUM> the guest partition <NUM> has direct access to and which parts of the physical device control plane <NUM> are virtualized can be determined in a variety of different manners. For example, the control plane interface <NUM> can be pre-configured with an indication of which parts of the physical device control plane <NUM> the guest partition <NUM> has direct access to and which parts are virtualized. By way of another example, the control plane interface <NUM> can obtain an indication of which parts of the physical device control plane <NUM> the guest partition <NUM> has direct access to and which parts are virtualized from a remote service (e.g., a service associated with the manufacturer of the physical device, the manufacturer of the computing device <NUM>, and so forth).

At least part of the physical device data plane <NUM> can be directly accessed by the guest partition <NUM> as discussed above. In one or more embodiments, at least part of the physical device data plane <NUM> can be virtualized. In such embodiments, the data plane interface <NUM> includes a control module <NUM> and an exposed physical device data plane <NUM>. The physical device data plane <NUM> is virtualized by the control plane interface <NUM> making an exposed physical device data plane <NUM> accessible to the guest partition <NUM>. The exposed physical device data plane <NUM> appears to the guest partition <NUM> as if it were the physical device data plane <NUM>, and the guest partition <NUM> need not be aware (and typically is not aware) that the exposed physical device data plane <NUM> is not actually the physical device data plane <NUM>.

Access requests (e.g., read and/or write requests) to the exposed physical device data plane <NUM> by the guest partition <NUM> are analyzed by the control module <NUM> and handled appropriately. The access requests can be analyzed and handled in a variety of different manners, analogous to the analyzing and handling performed by the control module <NUM> discussed above. In one or more embodiments, the control module <NUM> maintains a mapping of addresses in the exposed physical device data plane <NUM> to addresses in the physical device data plane <NUM>. The control module <NUM> uses this mapping to translate addresses in address requests received from the guest partition <NUM> to the appropriate address for the physical device data plane <NUM>.

Which parts of the physical device data plane <NUM> the guest partition <NUM> has direct access to and which parts of the physical device data plane <NUM> are virtualized can be determined in a variety of different manners. For example, the data plane interface <NUM> can be pre-configured with an indication of which parts of the physical device data plane <NUM> the guest partition <NUM> has direct access to and which parts are virtualized. By way of another example, the data plane interface <NUM> can obtain an indication of which parts of the physical device data plane <NUM> the guest partition <NUM> has direct access to and which parts are virtualized from a remote service (e.g., a service associated with the manufacturer of the physical device, the manufacturer of the computing device <NUM>, and so forth).

It should also be noted that, analogous to the discussion above regarding pages of memory in the exposed physical device control plane <NUM>, pages of memory in the exposed physical device data plane <NUM> can be mapped to pages of the physical device data plane <NUM> in a non-sequential order. The order in which the pages of memory in the exposed physical device data plane <NUM> are mapped to pages of the physical device data plane <NUM> can be determined in a variety of different manners, such as being pre-configured in the data plane interface <NUM>, being obtained from a remote service (e.g., a service associated with the manufacturer of the physical device, the manufacturer of the computing device <NUM>, etc.), and so forth.

<FIG> illustrates an example of mapping pages of the physical device data and control planes to pages of the exposed physical device data and control planes in accordance with one or more embodiments. Illustrated in the example of <FIG> is a physical device <NUM> and a virtual device <NUM>. The physical device <NUM> can be any of physical devices <NUM> of <FIG>. The virtual device <NUM> is a virtualized device that is exposed to a guest partition (e.g., any of guest partitions <NUM> of <FIG>). Also illustrated are the control plane interface <NUM> and the data plane interface <NUM>.

The physical device <NUM> includes the physical device control plane <NUM> and the physical device data plane <NUM>. The physical device data plane <NUM> includes multiple regions, shown as Region <NUM>, Region <NUM>, Region <NUM>, Region <NUM>, and Region <NUM>. The physical device <NUM> is a memory mapped I/O device, and each of the regions of the physical device data plane <NUM> is a memory address range that is associated with physical memory of the computing device <NUM> implementing the control plane interface <NUM> and the data plane interface <NUM>.

The virtual device <NUM> includes a mapped physical device control plane <NUM> and a mapped physical device data plane <NUM>. The mapped physical device control plane <NUM> is exposed by the control plane interface <NUM> to guest partitions as the exposed physical device control plane. Similarly, the mapped physical device data plane <NUM> is exposed by the data plane interface <NUM> as the exposed physical device data plane.

The mapped physical device control plane <NUM> is mapped by the control plane interface <NUM> to memory addresses of the physical device control plane <NUM> that are associated with the physical device <NUM>. The mapped physical device data plane <NUM> is mapped by the data plane interface <NUM> to memory addresses of the physical device data plane <NUM> that are associated with the physical device <NUM>. The mapped physical device data plane <NUM> includes multiple regions, shown as Region <NUM>, Region <NUM>, Region <NUM>, Region <NUM>, and Region <NUM>. However, the data plane interface <NUM> maps the regions of the mapped physical device data plane <NUM> to regions of the physical device data plane <NUM> in non-sequential order. As illustrated in <FIG>, Region <NUM> of mapped physical device data plane <NUM> is mapped by the data plane interface <NUM> to Region <NUM> of the physical device data plane <NUM>, Region <NUM> of mapped physical device data plane <NUM> is mapped by the data plane interface <NUM> to Region <NUM> of the physical device data plane <NUM>, Region <NUM> of mapped physical device data plane <NUM> is mapped by the data plane interface <NUM> to Region <NUM> of the physical device data plane <NUM>, Region <NUM> of mapped physical device data plane <NUM> is mapped by the data plane interface <NUM> to Region <NUM> of the physical device data plane <NUM>, and Region <NUM> of mapped physical device data plane <NUM> is mapped by the data plane interface <NUM> to Region <NUM> of the physical device data plane <NUM>.

<FIG> is a flowchart illustrating an example process <NUM> for managing guest partition access to physical devices in accordance with one or more embodiments. Process <NUM> is carried out by a device, such as computing device <NUM> of <FIG>, and can be implemented in software, firmware, hardware, or combinations thereof. Process <NUM> is shown as a set of acts and is not limited to the order shown for performing the operations of the various acts. Process <NUM> is an example process for managing guest partition access to physical devices; additional discussions of managing guest partition access to physical devices are included herein with reference to different figures.

In process <NUM>, a physical device to be made accessible to a guest partition of a computing device is identified (act <NUM>). The physical device can be identified in various manners, such as being pre-configured in a host of the computing device, being obtained from a remote service, and so forth. All physical devices in the computing device may be made accessible to the guest partition, or alternatively less than all of the physical devices in the may be made accessible to the guest partition.

A portion of the physical device that includes at least part of a control plane for the physical device is virtualized (act <NUM>). This virtualization can include mapping different parts of a physical device control plane that is exposed to the guest partition to the control plane of the physical device.

Access to the virtualized portion of the physical device by the guest partition is managed (act <NUM>). This management includes mapping access requests from an exposed physical device control plane to the physical device control plane. Various additional rules or criteria can also be implemented as discussed above to determine whether to perform the received access requests on the physical device.

The guest partition is allowed to directly access an additional portion of the physical device that includes at least part of the data plane for the physical device (act <NUM>). This additional portion is not virtualized, allowing the guest partition faster access to the additional portion of the physical device.

Returning to <FIG>, it should be noted that the mappings maintained in the control plane interface <NUM> and/or data plane interface <NUM> can change over time. These changes can be made during operation of the computing device <NUM>, and multiple such changes can be made in the time span between powering on the computing device <NUM> and powering off the computing device <NUM>. For example, when the computing device <NUM> powers on, a first guest partition can be allowed direct access to part of the physical device data plane. At some later time or in response to some event, such as switching to executing a second guest partition, the part of the physical device data plane for which the first guest partition was given direct access can be virtualized. At some further later time or in response to some other event, such as switching to executing the first guest partition again, the first guest partition can again be given direct access to the part of the physical device data plane for which the first guest partition was previously given direct access.

The techniques discussed herein allow a single physical device to be split into multiple virtual devices by virtualizing parts of the physical device while giving direct access to only other parts of the physical device. The guest partitions need not be given full direct access to all of the physical device. By virtualizing at least part of the control plane of a physical device, the part of the control plane accessed by the guest partition is implemented in software or firmware, alleviating the need to have additional hardware to support control planes for multiple guest partitions.

Although particular functionality is discussed herein with reference to particular modules, it should be noted that the functionality of individual modules discussed herein can be separated into multiple modules, and/or at least some functionality of multiple modules can be combined into a single module. Additionally, a particular module discussed herein as performing an action includes that particular module itself performing the action, or alternatively that particular module invoking or otherwise accessing another component or module that performs the action (or performs the action in conjunction with that particular module). Thus, a particular module performing an action includes that particular module itself performing the action and/or another module invoked or otherwise accessed by that particular module performing the action.

<FIG> illustrates an example system generally at <NUM> that includes an example computing device <NUM> that is representative of one or more systems and/or devices that may implement the various techniques described herein. The computing device <NUM> may be, for example, a server of a service provider, a device associated with a client (e.g., a client device), an on-chip system, and/or any other suitable computing device or computing system.

The example computing device <NUM> as illustrated includes a processing system <NUM>, one or more computer-readable media <NUM>, and one or more I/O Interfaces <NUM> that are communicatively coupled, one to another. Although not shown, the computing device <NUM> may further include a system bus or other data and command transfer system that couples the various components, one to another. A system bus can include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures. A variety of other examples are also contemplated, such as control and data lines.

The processing system <NUM> is representative of functionality to perform one or more operations using hardware. Accordingly, the processing system <NUM> is illustrated as including hardware elements <NUM> that may be configured as processors, functional blocks, and so forth. This may include implementation in hardware as an application specific integrated circuit or other logic device formed using one or more semiconductors. The hardware elements <NUM> are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, processors may be comprised of semiconductor(s) and/or transistors (e.g., electronic integrated circuits (ICs)). In such a context, processor-executable instructions may be electronically-executable instructions.

The computer-readable media <NUM> is illustrated as including memory/storage <NUM>. The memory/storage <NUM> represents memory/storage capacity associated with one or more computer-readable media. The memory/storage <NUM> may include volatile media (such as random access memory (RAM)) and/or nonvolatile media (such as read only memory (ROM), Resistive RAM (ReRAM), Flash memory, optical disks, magnetic disks, and so forth). The memory/storage <NUM> may include fixed media (e.g., RAM, ROM, a fixed hard drive, and so on) as well as removable media (e.g., Flash memory, a removable hard drive, an optical disc, and so forth). The computer-readable media <NUM> may be configured in a variety of other ways as further described below.

The one or more input/output interface(s) <NUM> are representative of functionality to allow a user to enter commands and information to computing device <NUM>, and also allow information to be presented to the user and/or other components or devices using various input/output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone (e.g., for voice inputs), a scanner, touch functionality (e.g., capacitive or other sensors that are configured to detect physical touch), a camera (e.g., which may employ visible or non-visible wavelengths such as infrared frequencies to detect movement that does not involve touch as gestures), and so forth. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, tactile-response device, and so forth. Thus, the computing device <NUM> may be configured in a variety of ways as further described below to support user interaction.

The computing device <NUM> also includes a control and/or data plane interface <NUM>. The control and/or data plane interface <NUM> provides various management of access requests to a physical device by a guest partition, and can be a control plane interface <NUM> and/or data plane interface <NUM> of <FIG>, <FIG>, or <FIG>, as discussed above.

Various techniques may be described herein in the general context of software, hardware elements, or program modules. Generally, such modules include routines, programs, objects, elements, components, data structures, and so forth that perform particular tasks or implement particular abstract data types. The terms "module," "functionality," and "component" as used herein generally represent software, firmware, hardware, or a combination thereof. The features of the techniques described herein are platform-independent, meaning that the techniques may be implemented on a variety of computing platforms having a variety of processors.

"Computer-readable storage media" refers to media and/or devices that enable persistent storage of information and/or storage that is tangible, in contrast to mere signal transmission, carrier waves, or signals per se. Thus, computer-readable storage media refers to non-signal bearing media. The computer-readable storage media includes hardware such as volatile and non-volatile, removable and non-removable media and/or storage devices implemented in a method or technology suitable for storage of information such as computer readable instructions, data structures, program modules, logic elements/circuits, or other data. Examples of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, hard disks, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other storage device, tangible media, or article of manufacture suitable to store the desired information and which may be accessed by a computer.

"Computer-readable signal media" refers to a signal-bearing medium that is configured to transmit instructions to the hardware of the computing device <NUM>, such as via a network. Signal media typically may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as carrier waves, data signals, or other transport mechanism. Signal media also include any information delivery media. By way of example, and not limitation, communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media.

As previously described, the hardware elements <NUM> and computer-readable media <NUM> are representative of instructions, modules, programmable device logic and/or fixed device logic implemented in a hardware form that may be employed in some embodiments to implement at least some aspects of the techniques described herein. Hardware elements may include components of an integrated circuit or on-chip system, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), and other implementations in silicon or other hardware devices. In this context, a hardware element may operate as a processing device that performs program tasks defined by instructions, modules, and/or logic embodied by the hardware element as well as a hardware device utilized to store instructions for execution, e.g., the computer-readable storage media described previously.

Combinations of the foregoing may also be employed to implement various techniques and modules described herein. Accordingly, software, hardware, or program modules and other program modules may be implemented as one or more instructions and/or logic embodied on some form of computer-readable storage media and/or by one or more hardware elements <NUM>. The computing device <NUM> may be configured to implement particular instructions and/or functions corresponding to the software and/or hardware modules. Accordingly, implementation of modules as a module that is executable by the computing device <NUM> as software may be achieved at least partially in hardware, e.g., through use of computer-readable storage media and/or hardware elements <NUM> of the processing system. The instructions and/or functions may be executable/operable by one or more articles of manufacture (for example, one or more computing devices <NUM> and/or processing systems <NUM>) to implement techniques, modules, and examples described herein.

As further illustrated in <FIG>, the example system <NUM> enables ubiquitous environments for a seamless user experience when running applications on a personal computer (PC), a television device, and/or a mobile device. Services and applications run substantially similar in all three environments for a common user experience when transitioning from one device to the next while utilizing an application, playing a video game, watching a video, and so on.

In the example system <NUM>, multiple devices are interconnected through a central computing device. The central computing device may be local to the multiple devices or may be located remotely from the multiple devices. In one or more embodiments, the central computing device may be a cloud of one or more server computers that are connected to the multiple devices through a network, the Internet, or other data communication link.

In one or more embodiments, this interconnection architecture enables functionality to be delivered across multiple devices to provide a common and seamless experience to a user of the multiple devices. Each of the multiple devices may have different physical requirements and capabilities, and the central computing device uses a platform to enable the delivery of an experience to the device that is both tailored to the device and yet common to all devices. In one or more embodiments, a class of target devices is created and experiences are tailored to the generic class of devices. A class of devices may be defined by physical features, types of usage, or other common characteristics of the devices.

In various implementations, the computing device <NUM> may assume a variety of different configurations, such as for computer <NUM>, mobile <NUM>, and television <NUM> uses. Each of these configurations includes devices that may have generally different constructs and capabilities, and thus the computing device <NUM> may be configured according to one or more of the different device classes. For instance, the computing device <NUM> may be implemented as the computer <NUM> class of a device that includes a personal computer, desktop computer, a multi-screen computer, laptop computer, netbook, and so on.

The computing device <NUM> may also be implemented as the mobile <NUM> class of device that includes mobile devices, such as a mobile phone, portable music player, portable gaming device, a tablet computer, a multi-screen computer, and so on. The computing device <NUM> may also be implemented as the television <NUM> class of device that includes devices having or connected to generally larger screens in casual viewing environments. These devices include televisions, set-top boxes, gaming consoles, and so on.

The techniques described herein may be supported by these various configurations of the computing device <NUM> and are not limited to the specific examples of the techniques described herein. This functionality may also be implemented all or in part through use of a distributed system, such as over a "cloud" <NUM> via a platform <NUM> as described below.

The platform <NUM> may abstract resources and functions to connect the computing device <NUM> with other computing devices. The platform <NUM> may also serve to abstract scaling of resources to provide a corresponding level of scale to encountered demand for the resources <NUM> that are implemented via the platform <NUM>. Accordingly, in an interconnected device embodiment, implementation of functionality described herein may be distributed throughout the system <NUM>. For example, the functionality may be implemented in part on the computing device <NUM> as well as via the platform <NUM> that abstracts the functionality of the cloud <NUM>.

In the discussions herein, various different embodiments are described. It is to be appreciated and understood that each embodiment described herein can be used on its own or in connection with one or more other embodiments described herein. Further aspects of the techniques discussed herein relate to one or more of the following embodiments.

A method, implemented in a computing device, the method comprising: identifying, in a host of the computing device, a physical device to be made accessible to a guest partition of the computing device; virtualizing a first portion of the physical device for access to the physical device by the guest partition, the first portion including at least part of a control plane for the physical device; managing accesses to the first portion of the physical device by the guest partition; and allowing the guest partition to directly access a second portion of the physical device, the second portion including at least part of a data plane for the physical device.

Alternatively or in addition to any of the above described methods, any one or combination of: the first portion including at least part of the data plane for the physical device; one or more parts of the data plane for the physical device included in the first portion changing during operation of the computing device; the managing access to the first portion of the physical device by the guest partition comprising receiving an access request targeting a first address, the first address being a memory address in an exposed physical device control plane, mapping the first address to a second address, the second address being a memory address in the physical device control plane, and making the access request targeting the second address; the method further comprising determining part of the control plane to include in the first portion, the part of the control plane comprising less than all of the control plane, including the part of the control plane in an exposed physical device control plane but not including other parts of the control plane in the exposed physical device control plane; the method further comprising including, in the exposed physical device control plane, regions mapped to the part of the control plane in non-sequential order; the first portion comprising all of the control plane for the physical device; the method further comprising allowing the guest partition to directly access an additional part of the control plane for the physical device, the additional part of the control plane being a different part than the first portion of the physical device; the guest partition manager comprising a hypervisor; the guest partition manager comprising a host operating system.

A computing device comprising: a control plane interface configured to virtualize a first portion of a physical device for access to the physical device by a guest partition, the first portion including at least part of a control plane for the physical device, the control plane interface being further configured to manage access to the first portion of the physical device by the guest partition; and a data plane interface configured to virtualize a second portion of the physical device for access to the physical device by the guest partition, the second portion including part of a data plane for the physical device, the data plane interface being further configured to manage access to the second portion of the physical device by the guest partition, and allow the guest partition to directly access parts of the data plane that are not included in the second portion.

Alternatively or in addition to any of the above described computing devices, any one or combination of: one or more parts of the data plane for the physical device included in the second portion changing during operation of the computing device; the control plane interface being further configured to expose to the guest partition an exposed physical device control plane, the exposed physical device control plane mapping to part of the control plane of the physical device that is less than all of the control plane of the physical device; the exposed physical device control plane including regions mapped to the part of the control plane of the physical device in non-sequential order.

A computing device comprising: a processor; a physical device; and a computer-readable storage medium having stored thereon multiple instructions that, responsive to execution by the processor, cause the processor to: virtualize a first portion of the physical device for access to the physical device by the guest partition, the first portion including at least part of a control plane for the physical device; manage accesses to the first portion of the physical device by the guest partition; and allow the guest partition to directly access a second portion of the physical device, the second portion including at least part of a data plane for the physical device.

Alternatively or in addition to any of the above described computing devices, any one or combination of: the first portion including at least part of the data plane for the physical device; one or more parts of the data plane for the physical device included in the first portion changing during operation of the computing device; wherein to manage access to the first portion of the physical device by the guest partition is to receive an access request targeting a first address, the first address being a memory address in an exposed physical device control plane, map the first address to a second address, the second address being a memory address in the physical device control plane, and make the access request targeting the second address; the multiple instructions further causing the processor to determine part of the control plane to include in the first portion, the part of the control plane comprising less than all of the control plane, and include the part of the control plane in an exposed physical device control plane but not including other parts of the control plane in the exposed physical device control plane; the multiple instructions further causing the processor to include, in the exposed physical device control plane, regions mapped to the part of the control plane in non-sequential order.

Claim 1:
A method, implemented in a computing device, the method comprising:
identifying (<NUM>), in a host operating system of the computing device, a physical device to be made accessible to a guest partition of the computing device;
virtualizing (<NUM>), by the host operating system of the computing device, a first portion of the physical device for access to the physical device by the guest partition, the first portion including at least part of a control plane for the physical device, the virtualizing making an exposed physical device control plane accessible to the guest partition by the host operating system;
managing (<NUM>), by the host operating system of the computing device, accesses to the first portion of the physical device by the guest partition; and
allowing (<NUM>) the guest partition to directly access a non-virtualized second portion of the physical device, the non-virtualized second portion including at least part of a data plane for the physical device.