A device isolation access method based on ARM64 architecture virtualization mechanism

Abstract

The present invention relates to the field of virtual isolation technology, specifically providing a device isolation access method based on the ARM64 architecture virtualization mechanism, comprising the following steps: allocating a client virtual address and creating a first-stage address mapping page table; in response to a client accessing a device address space, generating a page fault, causing the processor to jump to an interrupt vector table for execution, and then to a data fault handler corresponding to the hypervisor for processing; entering a corresponding client page fault handler in the host operating system kernel based on the fault information to obtain a host physical address corresponding to the client physical address space; the corresponding client page fault handler in the host operating system kernel enters the hypervisor to transfer address space ownership; and creating a second-stage address mapping page table for the device address space. This solution solves the technical problem of a client being unable to achieve exclusive device access when using a virtual device.

Description

Technical Field

[0001] The present invention relates to the field of virtual isolation technology, and specifically provides a device isolation access method based on the ARM64 architecture virtualization mechanism. Background Art

[0002] In a virtualized environment, there are two main ways to use devices: virtual devices and device passthrough.

[0003] Virtual devices are hardware devices emulated in software by a virtual machine monitor (such as VmWare, QEMU, or CrosVM). Clients operate through these virtual devices without directly accessing the host's hardware. Common virtual devices include virtual disks, virtual network interfaces, and virtual graphics cards.

[0004] Device passthrough leverages hardware IOMMU support and VFIO software technology to pass the host's physical hardware devices (such as GPUs, network cards, storage devices, etc.) directly to the client. This allows the client to directly access the host's physical hardware devices without the need for simulation through a virtual machine monitor, greatly improving the performance of the client's access to hardware devices.

[0005] In the prior art, when a client uses a virtual device and needs to use the host's hardware devices, it must access the device through the host using a standard virtualization protocol. The client cannot directly access the device, let alone achieve isolated device access between the host and client. Although device passthrough uses IOMMU hardware support and VFIO software technology to enable direct client access to the device, it also enables exclusive client device access by transferring device ownership (binding the device to the VFIO driver). However, this exclusive access is not truly isolated access; it is achieved simply by binding the device to different drivers. The host operating system can still access the device by creating address space mappings and modifying the IOMMU configuration.

[0006] To address the above issues, on a platform based on the ARM64 virtualization mechanism, we can fully utilize the virtualization characteristics of the ARM64 architecture itself, use the ARM64 architecture's two-stage address mapping mechanism and multi-run-level mechanism to achieve true device isolation access, and ensure from the hardware that the device address space owned by the client cannot be accessed by the host unless the client actively gives up ownership of the device address space. Summary of the Invention

[0007] In order to overcome the above-mentioned defects, the present invention is proposed to provide a solution or at least partially solve the technical problem that the client cannot achieve exclusive device access when using a virtual device.

[0008] The present invention provides a device isolation access method based on the ARM64 architecture virtualization mechanism, comprising the following steps:

[0009] S1: Allocate the client virtual address, create the first stage address mapping page table based on the physical address and size of the device to be accessed in the client, and complete the mapping from the client virtual address to the client physical address;

[0010] S2: In response to the client accessing the device address space, a page fault is generated. The processor jumps to the interrupt vector table for execution. According to the configured interrupt vector table, the processor jumps to the corresponding page fault handler of the hypervisor for processing, obtains relevant fault information, exits the client, and returns to the host operating system kernel.

[0011] S3: In the host operating system kernel, according to the fault information, the corresponding client page fault handler is entered to determine whether the client physical address generating the page fault is in the access device address space. If so, the host physical address corresponding to the client physical address space is obtained.

[0012] S4: The corresponding guest page fault handler in the host operating system kernel enters the hypervisor to transfer the ownership of the address space, and transfers the ownership of the host device address space corresponding to the host physical address in S3 to the guest;

[0013] S5: Create the second stage address mapping page table of the device address space to complete the mapping of the guest physical address to the host physical address;

[0014] The processor completes the conversion of the client virtual address to the host physical address by traversing the first-stage address mapping page table in S1 and the second-stage address mapping page table in S5. At the same time, the client's isolated access to the device is achieved through the transfer of address space ownership in S4.

[0015] Furthermore, in S1, allocating the client virtual address includes the client user state program entering the client operating system kernel through mmap to allocate the client virtual address of the user space.

[0016] Furthermore, in S1, allocating the client virtual address includes the client operating system kernel allocating the client virtual address of the kernel space through the operating system kernel interface ioremap.

[0017] Furthermore, in S4, the corresponding client page fault handler in the host operating system enters the hypervisor to transfer the ownership of the address space, and transfers the ownership of the device address space of the host corresponding to the host physical address in S3 to the client, including:

[0018] In the Hypervisor, by traversing the corresponding host machine's second-stage address mapping page table, the page table entries of all levels of page tables corresponding to the device address space are invalidated.

[0019] Furthermore, in S5, creating a second-stage address mapping page table of the device address space to complete the mapping of the client physical address to the host physical address includes:

[0020] According to the client physical address where the fault occurs, the host physical address, and the size of the accessed device address space, traverse the page tables at all levels corresponding to the client physical address, build the corresponding page table entries, and complete the second stage mapping of the client physical address to the host physical address.

[0021] Working principle and beneficial effects of the present invention:

[0022] In the technical solution of the present invention, when a client needs to access the device address space, the host machine will use the virtualization mechanism of the ARM64 architecture to transfer the ownership of the corresponding address space on the device to the client, thereby ensuring from the hardware that the device address space owned by the client cannot be accessed by the host machine.

[0023] When the client accesses the device address space, since the first stage address translation and the second stage address translation are established, the processor's memory management unit will traverse the page tables of the two stages respectively to complete the translation process from the client virtual address to the client physical address and then to the host physical address.

[0024] By releasing the second-stage address translation of the corresponding device address space in the host machine, it is ensured that the host machine can no longer access the corresponding device address space, thereby achieving exclusive isolated access of the client machine to the device address space. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The disclosure of the present invention will be more easily understood with reference to the accompanying drawings. Those skilled in the art will readily appreciate that these drawings are for illustrative purposes only and are not intended to limit the scope of protection of the present invention. Furthermore, similar numbers in the drawings represent similar components, wherein:

[0026] Figure 1 This is an architectural diagram of a device isolation access method based on the ARM64 architecture virtualization mechanism of the present invention. DETAILED DESCRIPTION

[0027] Some embodiments of the present invention are described below with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are only used to explain the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0028] Figure 1This is an architectural diagram of a device isolation access method based on the ARM64 architecture virtualization mechanism of the present invention. Figure 1 As shown, a device isolation access method based on the ARM64 architecture virtualization mechanism in this embodiment utilizes the ARM64 architecture two-stage address mapping mechanism and the multi-operation level mechanism to achieve true device exclusive isolation access, mainly including the following steps S1-step S5.

[0029] Step S1: Allocate the client virtual address, create the multi-level page table required for the first stage address translation (i.e., Figure 1 Create the first stage address mapping page table in ), which varies according to the virtual addresses supported by the processor, and realizes the mapping of the guest virtual address GVA to the guest physical address GPA.

[0030] In this embodiment, the first-stage address mapping page table is created in the client operating system kernel. After the first-stage page table mapping is created, the client virtual address GVA can be converted into the client physical address GPA.

[0031] In one embodiment, when the client needs to access the device address space, one way is for the client user-state program to enter the client operating system kernel through mmap to allocate the client virtual address of the user space; another way is for the client operating system kernel to directly allocate the client virtual address of the kernel space through the operating system kernel interface ioremap.

[0032] Step S2: In response to the client accessing the device address space, a page fault data fault is generated, the processor jumps to the interrupt vector table for execution, jumps to the data fault handler of the Hypervisor according to the configured interrupt vector table, obtains relevant fault information, exits the client and returns to the host operating system kernel (i.e. Figure 1 Exception handling in ).

[0033] In this embodiment, the multi-level page table required for the first-stage address translation created by S1 is used to realize the translation of the client virtual address to the client physical address, but the translation of the client physical address to the host physical address in the second stage is not established. When accessing the device address space, a page fault data fault will be generated. The processor will jump to the data fault handler of the hypervisor according to the configured interrupt vector table to handle the data fault, obtain relevant fault information, exit the client and return to the host operating system kernel.

[0034] In this embodiment, a data fault refers to a client exiting execution due to data anomalies, interruptions, or other reasons. Page faults and page faults are a type of data fault, indicating that the client accessed unmapped address space. The aforementioned fault handling refers to data faults generated when a client accesses unmapped device address space during execution. This type of data fault is first handled by the hypervisor and then further handled by the host operating system kernel.

[0035] Step S3: In the host operating system kernel, the corresponding client page fault handler is entered according to the fault information. The page fault handler determines whether the client physical address that generates the page fault accesses the device address space. If so, it obtains the host physical address corresponding to the client physical address space. When the client generates a page fault from GPA to HPA, it will first interrupt to EL2. EL2 cannot handle it and then exits the client and puts it back to the host operating system kernel (i.e. host EL1). The host operating system kernel will further process the client's page fault (i.e. Figure 1 Page fault exception in ).

[0036] Step S4: The guest page fault handler in the host operating system kernel enters the Hypervisor to transfer the address space ownership (i.e. Figure 1 Device address space ownership transfer in ).

[0037] In this embodiment, before the client accesses the device address space, the ownership of the device address space belongs to the host, the device is managed by the host, and the client cannot access the device address space. When the client accesses the device address space, the host needs to transfer the ownership of the corresponding device address space to the client. The host no longer owns the ownership of the corresponding address space and can no longer access the corresponding device address space. In the hypervisor, by traversing the multi-level page table required for the second-stage address translation of the corresponding host (i.e., the second-stage address mapping page table), the page table entries of the page tables at all levels corresponding to the device address space are invalidated to ensure that the host can no longer access the corresponding device address space, thereby realizing the transfer of ownership of the device address space.

[0038] Step S5: Create the second stage address mapping page table of the device address space to complete the mapping of the client physical address to the host physical address (i.e. Figure 1 Creating the Stage 2 Address Mapping Page Table in ).

[0039] In this embodiment, the second stage address translation can only be established in the hypervisor. When S3 enters the hypervisor through an HVC call, it provides the client physical address that caused the fault, the host physical address, and the size of the accessed device address space. The second stage address translation traverses the page tables at all levels corresponding to the client physical address based on the client physical address that caused the fault, the host physical address, and the size of the accessed device address space, and constructs the corresponding page table entries, thereby completing the second stage mapping of the client physical address to the host physical address.

[0040] Based on the above steps S1 to S5, the address space corresponding to the device can be accessed normally only when the ownership of the device address space is held. When the client needs to access the device address space, the host will use the virtualization mechanism of the ARM64 architecture to transfer the ownership of the corresponding address space on the device to the client, thereby ensuring from the hardware that the device address space owned by the client cannot be accessed by the host. When the client accesses the device address space, since S1 establishes the first stage address translation and S5 establishes the second stage address translation, the processor's memory management unit will traverse the page tables of the two stages respectively to complete the conversion process from the client virtual address to the client physical address and then to the host physical address. In addition, since the second stage address translation of the corresponding device address space in the host is released in S4, it is ensured that the host can no longer access the corresponding device address space, thereby achieving exclusive isolated access to the device address space by the client.

[0041] It should be pointed out that although the various steps in the above embodiments are described in a specific order, those skilled in the art will understand that in order to achieve the effects of the present invention, different steps do not have to be performed in such an order. They can be performed simultaneously (in parallel) or in other orders. These changes are within the scope of protection of the present invention.

[0042] Here are some terms involved in the present invention.

[0043] 1. Host: A physical computer running virtualization software in a virtualized environment to support the client machines. The host provides the computing resources required for virtualization (such as CPU, memory, hard disk, network interfaces, and display devices) and allocates these resources to the client machines through virtualization technology.

[0044] 2. Client: A virtual computer created by virtualization software, running on the aforementioned host machine. The client has hardware resources simulated by the virtualization software (such as the CPU, memory, hard drive, network interface, and display device), forming an independent computing environment and capable of installing and running independent operating systems and applications.

[0045] 3. The ARM64 architecture uses multiple "Exception Levels" (ELs) when the processor is running. These ELs define different permission levels, each with different privileges and access controls:

[0046] EL0 (user program), the lowest privilege level, is the environment in which user applications run. Ordinary application code runs in this mode and does not have the ability to directly access hardware resources and privileged instructions. Programs cannot perform operations that directly interact with hardware, nor can they access resources provided by the operating system kernel.

[0047] EL1 (operating system kernel), the level at which the operating system kernel runs, has higher permissions, including system calls, hardware interrupt handlers, resource management, etc., and can access memory, hardware resources and all privileged instructions.

[0048] EL2 (Hypervisor) is the level at which the virtualization layer operates. It is typically used by a hypervisor, which manages the creation, scheduling, and execution of virtual machines within virtualization technology. In this mode, the hypervisor controls access permissions between the host and virtual machines, ensuring isolation between them.

[0049] 4. Two-stage address access

[0050] In order to solve the problem of client physical address space access in the ARM64 virtualization environment, the ARM64 architecture virtualization mechanism provides a two-stage address translation: the first stage address translation is used to convert the guest virtual address (GVA, Guest Virtual Address) into the guest physical address (GPA, Guest Physical Address). In the virtualization environment, the client cannot directly access the physical address space using GPA; the second stage address translation is used to convert the GPA generated in the first stage into the host physical address (HPA, Host Physical Address). Only by using HPA can the real physical address space be accessed.

[0051] Thus far, the technical solutions of the present invention have been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art may make equivalent changes or substitutions to the relevant technical features, and the technical solutions after such changes or substitutions will fall within the scope of protection of the present invention.

Claims

1. A device isolation access method based on the ARM64 architecture virtualization mechanism, characterized in that: The following steps are involved: S1: Allocate the client virtual address, create the first stage address mapping page table based on the physical address and size of the device to be accessed in the client, and complete the mapping from the client virtual address to the client physical address; S2: In response to the client accessing the device address space, a page fault occurs. The processor jumps to the interrupt vector table for execution. According to the configured interrupt vector table, the processor jumps to the data fault handler corresponding to the hypervisor for processing, obtains relevant fault information, exits the client, and returns to the host operating system kernel. S3: In the host operating system kernel, according to the fault information, the corresponding client page fault handler is entered to determine whether the client physical address generating the page fault is in the access device address space. If so, the host physical address corresponding to the client physical address space is obtained. S4: The corresponding guest page fault handler in the host operating system kernel enters the hypervisor to transfer the ownership of the address space, and transfers the ownership of the host device address space corresponding to the host physical address in S3 to the guest; S5: Create the second stage address mapping page table of the device address space to complete the mapping of the guest physical address to the host physical address; The processor completes the conversion of the client virtual address to the host physical address by traversing the first-stage address mapping page table in S1 and the second-stage address mapping page table in S5. At the same time, the client's isolated access to the device is achieved through the transfer of address space ownership in S4.

2. A device isolation access method based on the ARM64 architecture virtualization mechanism according to claim 1, characterized in that: In S1, allocating the client virtual address includes the client user state program entering the client operating system kernel through mmap to allocate the client virtual address of the user space.

3. The device isolation access method based on the ARM64 architecture virtualization mechanism according to claim 1 is characterized in that: In S1, allocating the client virtual address includes the client operating system kernel directly allocating the client virtual address of the kernel space through the operating system kernel interface ioremap.

4. The device isolation access method based on the ARM64 architecture virtualization mechanism according to claim 1 is characterized in that: In S4, the corresponding client page fault handler in the host operating system kernel enters the hypervisor to transfer the address space ownership, and transfers the device address space ownership of the host corresponding to the host physical address in S3 to the client, including: In the Hypervisor, by traversing the corresponding host machine's second-stage address mapping page table, the page table entries of all levels of page tables corresponding to the device address space are invalidated.

5. The device isolation access method based on the ARM64 architecture virtualization mechanism according to claim 1 is characterized in that: In S5, creating a second-stage address mapping page table of the device address space to complete the mapping of the client physical address to the host physical address includes: According to the client physical address where the fault occurs, the host physical address, and the size of the accessed device address space, traverse the page tables at all levels corresponding to the client physical address, build the corresponding page table entries, and complete the second stage mapping of the client physical address to the host physical address.

Images