Secure memory access in virtualized computing environments

Abstract

The processor [101] supports secure memory access in a virtualized computing environment by using a requestor identifier at a bus device [102] (such as a graphics processing unit) to identify a virtual machine [221, 222] associated with each memory access request. The virtualized computing environment uses the requestor identifier to control access to different regions [111, 112] of system memory [110], thereby ensuring that each VM accesses only those memory regions that the VM is allowed to access. The virtualized computing environment thereby supports efficient memory access by the bus device while ensuring that different regions of memory are protected from unauthorized access.

Description

Background Art

[0001] In a virtualized computing environment, multiple virtualized entities, called virtual machines (VMs), share computer resources while appearing or interacting with a user as separate computer systems. For example, a server can execute multiple VMs simultaneously, whereby each of the multiple VMs behaves as a separate computer system but shares the server's resources with the other VMs. A virtualized computing environment supports efficient use of computer resources, and those resources need to be carefully managed to ensure the security and correct operation of each of the VMs. For example, a virtualized computing environment typically manages access to system memory on behalf of a VM to ensure that a VM does not inadvertently or maliciously access data of other VMs. However, conventional memory access techniques for virtualized computing environments are inefficient, particularly when bus devices (devices coupled to a system interconnect) are allowed to directly access memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] By referring to the accompanying drawings, the present disclosure can be better understood, and its numerous features and advantages will be apparent to those skilled in the art. The use of the same reference numerals in different drawings indicates similar or identical items.

[0003] Figure 1 is a block diagram of a processing system that employs different request identifiers for different virtual machines to support access to memory by a bus device, according to some embodiments.

[0004] Figure 2 is a diagram showing the Figure 1 A block diagram of an example in which different virtual machines executing at a processing system access memory via a bus device using different request identifiers.

[0005] Figure 3 is a diagram showing that according to some embodiments Figure 1 A block diagram of an example of a processing system employing a device driver and a hypervisor to support secure memory access for different virtual machines.

[0006] Figure 4 is a flow chart of a method for a VM to access memory via a bus device using a request identifier according to some embodiments.

[0007] Figure 5 is a diagram showing that according to some embodiments Figure 1 A block diagram of an example of a processing system that handles interrupts independently of a host operating system.

[0008] Figure 6 is a diagram showing that according to some embodiments Figure 1 A flowchart of a method for a processing system to handle interrupts independently of a host operating system. DETAILED DESCRIPTION

[0009] Figures 1 to 6 A technique for supporting secure memory access in a virtualized computing environment by employing a requestor identifier at a bus device (such as a graphics processing unit) to identify a virtual machine associated with each memory access request is shown. The virtualized computing environment uses the requestor identifier to control access to different regions of system memory, thereby ensuring that each VM accesses only those memory regions that the VM is allowed to access. The virtualized computing environment thereby supports efficient memory access by the bus device while ensuring that different regions of memory are protected from unauthorized access.

[0010] To illustrate by example, in some embodiments, the graphics processing unit (GPU) of the processor is connected to the system memory via an input-output memory management unit (IOMMU). The processor executes multiple VMs simultaneously, and each VM uses the GPU to perform specified operations. For memory accesses caused by these operations, the GPU generates a memory access request, and includes a request identifier indicating the VM associated with the request in each memory access request. In response to receiving the memory access request, the IOMMU identifies a pointer to a set of page tables based on the request identifier, and uses the set of page tables to identify the system memory address for the memory access request. The page table is set by the hypervisor so that each VM can only access the corresponding area of ​​the system memory. Therefore, the processor protects each area of ​​the memory from unauthorized access, thereby ensuring the security and correct operation of each VM. In contrast, conventional processors do not support different requestor identifiers for different VMs at the bus device, thereby exposing different memory areas to unauthorized access, or limiting the concurrent use of the bus device by different VMs, thereby reducing system efficiency.

[0011] In some embodiments, the virtualized computing environment supports handling interrupts from a GPU or bus device independently of a host operating system (OS) executed in the environment. The GPU is configured to perform tasks on behalf of different concurrently executed guest OSs, each guest OS being associated with a different VM. The interrupt handling program maintains a mapping table between each task and the corresponding guest OS. The interrupt handling program receives an interrupt from the GPU, each interrupt including a payload having an embedded virtual memory identifier (VMID), the VMID identifying the virtual memory associated with the task generating the interrupt. The interrupt handling program cancels the reference to the virtual function identifier (VFID) from the mapping table, and based on the VFID, the interrupt payload is provided to the guest OS corresponding to the VFID. For example, in some embodiments, an interrupt with a VMID is provided to an interrupt handling program, which maps the VMID to the VFID. The interrupt handling program forwards the VFID to a controller (such as a PCIe controller), which maps the VFID to a request ID, and a module (e.g., an IOMMU) that handles the interrupt uses the request ID to handle the interrupt. The virtualized computing environment thus supports interrupt handling independently of the host OS, thereby reducing the overall interrupt latency.

[0012] Figure 1 1 is a block diagram of a processing system 100 that employs different request identifiers for different virtual machines to support access to memory by a bus device according to some embodiments. The processing system 100 is generally configured to execute an instruction set (e.g., a computer program) on behalf of an electronic device. Thus, in various embodiments, the processing system 100 is incorporated into any of a number of different electronic devices (such as a desktop computer, a laptop computer, a server, a smart phone, a game controller, etc.).

[0013] To facilitate execution of the instruction set, processing system 100 includes processor 101 and memory 110. In some embodiments, processor 101 is an accelerated processing unit (APU) configured to execute the instruction set, and memory 110 includes a set of memory modules (e.g., dynamic random access memory (DRAM) memory modules) that together form the system memory of processor 100. Thus, memory 110 stores data and instructions accessible to the instruction set executed at processor 101.

[0014] In the depicted example, processor 101 includes a graphics processing unit (GPU) 102 and an input / output memory management unit (IOMMU) 105. It should be understood that in some embodiments, processor 101 includes additional modules that support instruction execution, including one or more central processing unit (CPU) cores, a memory controller that supports CPU core access to memory, one or more caches, one or more input / output modules, etc. GPU 102 is generally configured to perform multiple groups of operations, referred to as workloads, in response to receiving the operations from one or more CPU cores. The multiple groups of operations are generally associated with graphics and vector instructions executed at processor 101.

[0015] The IOMMU 105 is generally configured to provide an interface between select modules of the processor 101 including the GPU 102 and the memory 110. In some embodiments, the IOMMU provides direct memory access (DMA) functionality to the memory 110 for the select modules. Thus, the IOMMU 105 is configured to receive memory access requests (read and write requests) from the GPU 102 and other modules, translate virtual addresses associated with the memory access requests into physical addresses, and manage providing memory access requests to the memory 110 with physical addresses and managing responses to the provided memory access requests. In some embodiments, the IOMMU 105 is connected to the GPU 102 and other modules via an interconnect (referred to herein as a bus) that operates according to a specified interconnect protocol, such as the Peripheral Component Interconnect Express (PCI-e) protocol. Modules that provide memory access requests to the IOMMU 105 via the bus are referred to herein as "bus devices." For simplicity, the interaction between the GPU 102 and the IOMMU 105 is described. Figure 1 However, it should be understood that the techniques described herein are applicable to and may be implemented with any bus device.

[0016] In some embodiments, processing system 100 is used in a variety of environments where it is important to protect data associated with one instruction set from being accessed by other instruction sets. For example, in some scenarios, processing system 100 is used in a virtualized computing environment where processing system 100 executes multiple virtual machines (VMs) simultaneously. Allowing a VM to access at least a subset of data associated with another VM can sometimes result in VM operation errors or expose private data to unauthorized access. Therefore, in Figure 1 In the example of , the processing system 100 divides at least a portion of the memory 110 into different regions (eg, regions 111 , 112 ) and allocates each region to a corresponding VM.

[0017] In order to protect regions of memory 110 from unauthorized access, the IOMMU 105 employs a different set of page tables (e.g., page tables 116, 117) for each VM. During initialization of the VM, a management entity (e.g., a hypervisor) establishes a corresponding page table, wherein the page table identifies a physical address associated with a virtual address used by the VM. The management entity generates a page table for the VM such that the physical address corresponds to a region of memory 110 allocated to the VM. In addition, the management entity creates a set of page table pointers 115, wherein each page table pointer points to a different page table. The page table pointers 115 also include an identifier for each page table pointer, which the IOMMU uses to identify a memory access request for a given set of tables, as further described below.

[0018] GPU 102 employs context identifiers (e.g., context IDs 106, 107) to manage workloads for executing VMs. Thus, in response to receiving a workload from a VM, GPU 102 creates a context ID for the workload. In some embodiments, each context ID itself uniquely identifies the VM that created the workload. In other embodiments, GPU 102 reuses a given context ID for workloads from different VMs and identifies the VM that created the workload based on a combination of the context ID and other indicators (such as the timing or order in which the workload was received). When generating a memory access request for a workload, GPU 102 identifies the VM that created the workload and includes a request identifier (e.g., request ID 109) identifying the VM in the memory access request.

[0019] In response to receiving a memory access request, the IOMMU 105 uses the request ID to index the set of page table pointers 115 to identify the page table associated with the VM. The IOMMU 105 uses the identified page table to perform a page table walk to convert the virtual address of the memory access request into a physical address. The IOMMU 105 then provides the physical address to the memory 110 to satisfy the memory access request at the area assigned to the VM. Therefore, by using the request ID, the processing system 100 allows the GPU 102 (or any bus device) to directly access the memory 110 via the IOMMU 105 while protecting each area of ​​the memory 110 from unauthorized access.

[0020] In some embodiments, processing system 100 utilizes one or more existing bus protocol fields to store a request ID for a memory access request. For example, the PCIE protocol includes a device identifier field to indicate a device that generates a message such as a memory access request. GPU 102 uses the device identifier field to store a request ID that identifies the VM that generated the memory access request. By using existing bus protocol fields, the implementation of the request ID can be simplified.

[0021] Figure 2 208. 209. 201. 202. 203. 204. 205. 206. 207. 208. 209. 201. 201. 202. 203. 204. 205. 206. 207. 208. 209. 201. 202. 203. 204. 205. 206. 207. 208. 209. 201. 202. 203. 204. 205. 206. 207. 208. 209. 209. 201. 202. 203. 204. 205. 206. 207. 208. 209. 209. 201. 202. 203. 204. 205. 206. 207. 208. 209. 209. 209. 209. 201. 201. 202. 203. 204. 205. 206. 207. 208. 209 ...

[0022] VFi_ReqID==PF ReqID+VF_OFFSET+VF#*VF_STRIDE

[0023] Where VF_OFFSET and VF_STRIDE are values ​​used to index into a linked list of VFs associated with a given physical function.

[0024] In addition, due to Figure 2 For purposes of example, assume that during configuration, the hypervisor allocates region 111 of memory 110 to VM 221 and allocates region 112 to VM 222. Therefore, during configuration of VM 221, the hypervisor generates page table 116 for VM 221 such that the physical addresses stored at page table 116 correspond to region 111. Similarly, the hypervisor generates page table 117 for VM 222 such that the physical addresses stored at page table 116 correspond to region 111.

[0025] In operation, GPU 102 generates memory access requests based on the workload generated by VM 221 and based on the workload generated by VM 222. In response to generating a memory access request for the workload generated by VM 221, the GPU includes request ID 208 in the memory access request. Similarly, in response to generating a memory access request for the workload generated by VM 222, the GPU includes request ID 209 in the memory access request.

[0026] In response to receiving a memory access request, the IOMMU 105 uses the request ID received in the memory access request to index the page table pointer 115. Thus, for a memory access request including the request ID 208, the IOMMU 105 indexes the page table pointer 115 to retrieve a pointer to the page table 116. For a memory access request including the request ID 209, the IOMMU 105 indexes the page table pointer 115 to retrieve a pointer to the page table 117. The IOMMU 105 performs a page walk on the page table indicated by the retrieved pointer, thereby translating the virtual address received in the memory access request into a physical address. Depending on the VM associated with the memory access request, the physical address corresponds to one of the regions 111 and 112.

[0027] Figure 3 3 is a block diagram illustrating an example of a processing system 100 employing a device driver and a hypervisor to support secure memory access for different virtual machines according to some embodiments. In the depicted example, the processing system executes a hypervisor 330, which is generally configured to manage the configuration and execution of virtual machines at the processing system 100. In various embodiments, the hypervisor 330 is software, hardware, or a combination thereof.

[0028] As mentioned above, the hypervisor 330 is generally configured to manage the configuration of the VM at the processing system 101. Therefore, in response to receiving a request to start the execution of the VM, the hypervisor 330 manages the generation of a page table for the VM to be stored at the IOMMU 105, and the generation of a page table pointer pointing to the generated page table. The driver (not shown) manages the mapping of the VMID to the VFID, and the hypervisor 330 manages the generation of the request ID from the VFID according to the above formula. The hypervisor 330 further ensures that the request ID for the VM is associated with the corresponding page table pointer at the IOMMU 105.

[0029] exist Figure 3In the example of , processing system 100 executes device drivers 332 and 333. Each of device drivers 332 and 333 provides a software interface between the GPU and the corresponding VM (VM 221 and 222, respectively). Thus, each of device drivers 332 and 333 receives a request to execute a workload from the corresponding VM, translating the request into one or more commands formatted according to a specific type of GPU 102. Device drivers 332 and 333 also receive messages from GPU 102, such as messages indicating the results of the workload executed by GPU 102. Device drivers 332 and 333 translate the message (or its data payload) into the format expected by the corresponding VM and provide the translated information to the VM.

[0030] In some embodiments, GPU 102 identifies the request ID for memory access request based on the device driver providing the workload or command. Specifically, since each device driver 332 and 333 is uniquely associated with different VMs 221, 222, GPU 102 actually identifies the VM providing the workload or command by identifying the device driver providing the workload or command. Based on the identified VM, GPU 102 includes the request ID associated with the identified VM in the memory access request. In some embodiments, VM 221 and 222 share the device driver to dock with GPU 102. Therefore, in the case of providing each command or workload to GPU 102, the device driver includes a virtual memory identifier (VMID). GPU 102 uses VMID to identify the request ID to be included in each memory access request. In some embodiments, each VMID is uniquely associated with different VMs. In other embodiments, the VMID is shared by multiple VMs, and GPU 102 identifies the request ID for the VM based on a combination of the VMID and other context information (such as when the request ID was generated, when the interrupt was received, which VMs are currently executing, etc.).

[0031] Figure 4 is a flow chart of a method 400 for a VM to access memory via a bus device using a request identifier according to some embodiments. Figures 1 to 3 1. The method 400 is described in an exemplary embodiment at the processing system 100 of FIG. At block 402, the GPU 102 generates a memory access request based on executing a workload on behalf of the VM. The GPU 102 identifies a context ID for the VM based on, for example, one or more of the device drivers providing the workload, based on the VMID of the VM provided by the device driver, or a combination thereof. At block 404, the GPU 102 determines a request ID for the VM based on the context ID.

[0032] At box 406, GPU 102 sends a memory access request to IOMMU 105, and causes the memory access request to include a request ID. For example, in some embodiments, GPU 102 includes a request ID identifying the VM in a field of the memory access request reserved for the device identifier to identify the device of processing system 100. At box 408, IOMMU 105 accesses page table pointer 115 and identifies the page table pointer for the VM based on the request ID. At box 410, IOMMU 105 accesses a set of page tables indicated by the page table pointer and uses the set of page tables to perform a page table walk to translate the virtual address of the memory access request into a physical address. At box 410, IOMMU 105 uses the physical address to access memory 110. The physical address is located in the area assigned to the VM associated with the memory access request. Therefore, each VM only accesses its corresponding area, thereby protecting each VM data from unauthorized access.

[0033] Figure 5 5 is a block diagram illustrating an example of processing system 100 handling interrupts according to some embodiments. In the depicted example, processing system 100 concurrently executes host OS 544, guest OS 546, and guest OS 548. Each of OS 544, 546, and 548 executes at one or more processor cores (not shown) of processing system 100. Host OS 544 is an operating system that is typically configured to perform operating system functions such as application and memory management for processing system 100. Each of guest OS 544 and 546 is configured to perform operating system functions for a different corresponding VM executing at processing system 100. Thus, for example, in some embodiments, guest OS 546 is a guest OS 548 that is executed by VM 221 ( Figure 2 ) is an operating system executed by VM 222, while guest OS 548 is an operating system executed by VM 222.

[0034] As explained above, in some embodiments, each of VM 221 and 222 assigns tasks such as drawing tasks, vector calculation tasks, etc. to GPU 102 for execution. In the process of performing these tasks, GPU 102 generates an interrupt (e.g., interrupt 550) to asynchronously provide information such as state information to the corresponding VM. For example, in some embodiments, GPU 102 generates an interrupt when completing a specified task for VM, and the interrupt includes a payload indicating task results or other state information. Conventionally, interrupt handling for VMs executed simultaneously is routed by the host OS or by using dedicated hardware. For example, in some processing systems, all interrupts are first provided to the host OS, and the host OS identifies the VM to which the interrupt is directed, and then the interrupt is routed to the identified VM. However, this method causes a relatively long waiting time for interrupt handling.

[0035] Compared to conventional methods, the processing system 100 uses a mapping table 542 and an interrupt handling program 540 to handle interrupts of guest OS 546 and 548 independently of the host OS 544. The mapping table 542 indicates the corresponding VFID for each VMID, and further indicates the area of ​​memory 110 (or other memory of the processing system 100) allocated to the VFID. Each interrupt generated by the GPU 102 includes a VMID identifying the VM corresponding to the task generating the interrupt. In response to receiving the interrupt, the interrupt handling program 540 accesses the mapping table 542 to identify the VFID associated with the VMID and the memory area associated with the VFID. The interrupt handling 540 stores the payload of the interrupt at the indicated memory area, where the corresponding guest OS accesses the payload to provide it to the application or other module being executed. In some embodiments, during the initialization phase, the area is allocated to the VFID by the host OS 544 or by the hypervisor of the processing system 100, so that different memory areas are allocated for each VM (and the corresponding guest OS), thereby ensuring that the guest OS only accesses the payload of the interrupt for the VM. That is, the guest OS does not "know" the memory area allocated to other VMs and therefore cannot access the interrupt payloads of other VMs, thereby protecting the interrupt payloads from improper access. In some embodiments, the interrupt payload is routed to the VM via the IOMMU 105, and the interrupt itself or its indicator is provided to the IOMMU 105 using a different set of tables (not shown) and other interrupt-specific mechanisms to inject the interrupt into the virtual machine.

[0036] In some embodiments, interrupt handling program 540 handles interrupts for guest OS 546 and 548 independently of host OS 544. That is, host OS 544 does not handle the provision of interrupts or interrupt payloads to guest OS 546 and 548. Processing system 101 thereby reduces latency associated with interrupt handling for virtual machines.

[0037] Figure 6 is a flow chart of a method 600 of handling interrupts of a VM at a processing system independently of a host OS, according to some embodiments. Figure 1 and Figure 5 6. The exemplary embodiment of the method 600 at the processing system of FIG. 602, the interrupt handling program 540 receives the interrupt 550 from the GPU 102. In response, at box 604, the interrupt handling program 540 uses the VMID included in the interrupt 550 to access the mapping table 542. The mapping table indicates the VFID associated with the interrupt, and at box 606 indicates the memory area corresponding to the VFID. At box 608, the interrupt handling program 540 stores the data payload of the interrupt 550 at the indicated memory area and indicates to the guest OS corresponding to the VFID that the interrupt has been received. In response, the guest OS accesses the data payload stored in the memory area.

[0038] As disclosed herein, in some embodiments, a method includes: receiving a first memory access request from a bus device at an input / output memory management unit (IOMMU), the first memory access request including a first memory address and a first request identifier indicating a first virtual machine (VM) associated with the first memory access request; and satisfying the first memory access request at a memory in response to determining at the IOMMU that the first virtual machine is authorized to access a first memory region associated with the first memory address based on mapping a virtual memory identifier (VMID) to a virtual function identifier (VFID). In one aspect, mapping the VMID to the VFID includes mapping the first request identifier to the VFID. In another aspect, mapping the first request identifier to the VFID includes mapping based on an index to an offset value of a virtual function linked list.

[0039] In one aspect, mapping the first request identifier to the VFID includes mapping based on a stride value indexed to the virtual function linked list. In another aspect, mapping the first request identifier to the VFID based on the stride value includes multiplying the stride value by a virtual function number corresponding to the virtual function. In yet another aspect, the first request identifier is stored at a field of the memory access request reserved for a device identifier. In yet another aspect, the method includes identifying the first request identifier based on a device driver associated with the bus device. In another aspect, the method includes accessing a set of page tables based on the mapping. In yet another aspect, the method includes: receiving a second memory access request from the device at the IOMMU, the second memory access request including a second memory address and a second request identifier indicating a second virtual machine (VM) associated with the second memory access request; and in response to determining at the IOMMU that the second virtual machine is authorized to access a second memory region associated with the first memory address based on mapping a virtual memory identifier (VMID) to a virtual function identifier (VFID), satisfying the second memory access request at the memory.

[0040] As disclosed herein, in some embodiments, a method includes: in response to receiving an interrupt from a bus device, identifying a memory region based on mapping a virtual machine identifier (VMID) associated with the interrupt to a virtual function; and storing a payload of the interrupt at the memory region. In one aspect, the method includes retrieving the payload from the memory region by a guest operating system.

[0041] As disclosed herein, in some embodiments, a processor includes: a bus device for executing a workload on behalf of a first virtual machine (VM); and an input / output memory management unit (IOMMU), the IOMMU being configured to: receive a first memory access request from the bus device, the first memory access request including a first memory address and a first request identifier indicating the first VM; and in response to determining at the IOMMU that the first virtual machine is authorized to access a first memory region associated with the first memory address based on mapping a virtual machine identifier (VMID) to a virtual function identifier (VFID), satisfying the first memory access request at a memory. In one aspect, the IOMMU is configured to map the VMID to the VFID by mapping the first request identifier to the VFID. In another aspect, the IOMMU is configured to map the first request identifier to the VFID by mapping based on an offset value indexed to a virtual function linked list.

[0042] In one aspect, the IOMMU is configured to map the first request identifier to the VFID by mapping based on a stride value indexed to the virtual function linked list. In another aspect, the IOMMU is configured to map the first request identifier to the VFID by multiplying the stride value by a virtual function number corresponding to the virtual function. In yet another aspect, the first request identifier is stored at a field of the memory access request reserved for a device identifier. In yet another aspect, the bus device is configured to: identify the first request identifier based on a device driver associated with the bus device. In another aspect, the IOMMU is configured to: access a set of page tables based on the mapping. In yet another aspect, the IOMMU is configured to: receive a second memory access request from the device, the second memory access request including a second memory address and a second request identifier indicating a second virtual machine (VM) associated with the second memory access request; and in response to determining that the second virtual machine is authorized to access a second memory region associated with the first memory address, satisfy the second memory access request at the memory.

[0043] In some embodiments, certain aspects of the techniques described above may be implemented by one or more processors of a processing system that executes software. The software includes one or more executable instruction sets that are stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. The software may include instructions and certain data that manipulate one or more processors to perform one or more aspects of the techniques described above when executed by one or more processors. The non-transitory computer-readable storage medium may include, for example, a magnetic or optical disk storage device, a solid-state storage device, such as a flash memory, a cache, a random access memory (RAM), or one or more other non-volatile memory devices, etc. The executable instructions stored on the non-transitory computer-readable storage medium may be source code, assembly language code, object code, or other instruction formats that may be interpreted or executed by one or more processors.

[0044] It should be noted that not all activities or elements described above in the general description are required, a part of a particular activity or device may not be required, and in addition to the described activities or elements, one or more additional activities may be performed or one or more additional elements may be included. Furthermore, the order in which the activities are listed is not necessarily the order in which the activities are performed. In addition, concepts have been described with reference to specific embodiments. However, it should be understood by those of ordinary skill in the art that various modifications and changes may be made without departing from the scope of the present disclosure set forth in the appended claims. Therefore, the specification and drawings should be regarded as illustrative rather than restrictive, and all such modifications are intended to be included within the scope of the present disclosure.

[0045] Benefits, other advantages and solutions to problems have been described above with respect to specific embodiments. However, these benefits, advantages, solutions to problems, and any functions that may cause any benefit, advantage or solution to occur or become more obvious should not be interpreted as key, essential or basic features of any or all claims. In addition, the specific embodiments disclosed above are merely illustrative, because the disclosed subject matter can be modified and practiced in different but equivalent ways that are obvious to those skilled in the art who benefit from the teachings of this article. Except as described in the appended claims, it is not intended to limit the details of the construction or design shown herein. Therefore, it is obvious that the specific embodiments disclosed above can be changed or modified, and all such changes are considered to be within the scope of the disclosed subject matter. Therefore, the protection sought herein is as set forth in the appended claims.

Claims

1. A method comprising: receiving, at an input / output memory management unit IOMMU, a first memory access request from a bus device, the first memory access request comprising a first memory address and a first request identifier indicating a first virtual machine VM associated with the first memory access request; and In response to determining at the IOMMU that the first virtual machine is authorized to access a first memory region associated with a first memory address based on mapping a virtual memory identifier VMID to a virtual function identifier VFID, the first memory access request is satisfied at a memory. 2 . The method of claim 1 , wherein mapping the VMID to the VFID comprises mapping the first request identifier to the VFID.

3. The method of claim 2, wherein mapping the first request identifier to the VFID comprises mapping based on an offset value indexed into a virtual function linked list.

4. The method of claim 3, wherein mapping the first request identifier to the VFID comprises mapping based on an index into a stride value of the virtual function linked list. 5 . The method of claim 4 , wherein mapping the first request identifier to the VFID based on the stride value comprises multiplying the stride value by a virtual function number corresponding to a virtual function.

6. A method as claimed in any preceding claim, wherein: The first request identifier is stored at a field of the memory access request reserved for a device identifier.

7. The method according to any one of claims 1 to 5, further comprising: The first request identifier is identified based on a device driver associated with the bus device.

8. The method of claim 1, further comprising: A set of page tables is accessed based on the mapping.

9. A processor comprising: A bus device, the bus device being used to execute a workload on behalf of a first virtual machine VM; as well as An input / output memory management unit IOMMU, the IOMMU being configured to: receiving a first memory access request from the bus device, the first memory access request comprising a first memory address and a first request identifier indicating the first VM; and In response to determining at the IOMMU that the first virtual machine is authorized to access a first memory region associated with a first memory address based on mapping a virtual machine identifier VMID to a virtual function identifier VFID, the first memory access request is satisfied at a memory.

10. The processor of claim 9, wherein the IOMMU is configured to map the VMID to the VFID by mapping the first request identifier to the VFID.

11. The processor of claim 10, wherein the IOMMU is configured to map the first request identifier to the VFID by mapping based on an offset value indexed into a virtual function linked list.

12. The processor of claim 11, the IOMMU configured to map the first request identifier to the VFID by mapping based on an index to a stride value of the virtual function linked list.

13. The processor of claim 12, wherein the IOMMU is configured to map the first request identifier to the VFID by multiplying the stride value by a virtual function number corresponding to a virtual function.

14. A processor as claimed in any one of claims 9 to 13, wherein: The first request identifier is stored at a field of the memory access request reserved for a device identifier.

15. The processor according to any one of claims 9 to 13, wherein the bus device is configured to: The first request identifier is identified based on a device driver associated with the bus device.

Images