Method for acquiring Guest OS running state information under Jailhouse

Abstract

The invention relates to the technical field of virtual machines, in particular to a method for acquiring Guest OS running state information under Jailhou.The method comprises the steps that a Trace area is newly added for each Guest OS on an ivshmem memory communication model, and the Trace area comprises a conf area and a running state area; before the Host Linux starts the Guest OS, the system running state information of the Guest OS to be checked is written in the conf area of the corresponding Trace area; after the Guest OS is powered on, default Trace configuration information is read, and a corresponding Trace area address is obtained; and according to the Trace region address, reading the system running state information of the Guest OS to be checked, and writing the corresponding running state information into the running state region of the Trace region according to a certain format. Through the scheme, the problem that the Guest OS running state information is inconvenient to obtain by using a traditional method based on a physical serial port or a physical network port in a Jailhouse environment is solved.

Description

Technical Field

[0001] The present invention relates to the technical field of virtual machines, and specifically provides a method for obtaining the running state information of a Guest OS under Jailhouse. Background Art

[0002] Jailhouse is a Linux-based partition virtual machine manager (Hypervisor) designed to provide a secure and isolated multi-operating system running environment for a hardware platform. Different from traditional virtual machines, Jailhouse does not simulate new hardware. It adopts a unique architecture design that divides hardware resources into multiple independent units (Cells), and each unit can run different operating systems or bare-metal applications to achieve efficient multi-operating system isolation. In Jailhouse, there is a special unit called Root Cell. Root Cell runs Host Linux and controls some resources of the entire system. However, it does not completely control hardware resources like traditional Dom0. Instead, when a new Cell is created, it will transfer the control rights of the corresponding CPU, device, and memory resources to the new Cell.

[0003] With the continuous improvement of system integration, modern processors often come with multiple cores, and each core can run an independent Cell. Depending on the complexity of the system, multiple Cells may be allocated, and thus multiple Guest OSs may run on one core. While this architecture provides powerful computing capabilities, monitoring the actual running states and records of these Guest OSs also poses new challenges to each core.

[0004] For the Guest OS monitoring method, generally the following two methods can be adopted. One is to monitor the state of the Guest OS through a real physical serial port, physical network port, or external emulation debugger. The disadvantage of this method is that it not only occupies scarce peripheral resources but also may require external dedicated debugging devices, bringing many inconveniences to the deployment and use of the system and having obvious limitations. The other is to use the virtualized memory communication technology ivshmem (Inter-VM shared memory). The virtual network function provided by ivshmem assigns independent virtual network interfaces to each Guest OS. Through these virtual network interfaces, network monitoring tools can be used to monitor the state. However, this technology requires the Guest OS side to support network ports. In some scenarios, the Guest OS is usually a real-time operating system RTOS with high requirements for system real-time performance. In some scenarios, network functions are not required. And if virtual network functions (network ports) are added to increase the state display function, it will undoubtedly have a certain impact on the real-time performance and resources of RTOS.

[0005] As Figure 1 shown, the current ivshmem provides three memory types. The specific ivshmem memory communication model includes: The first part consists of a required State Table, whose size is defined by the State Table Size register and cannot be zero. This part is read-only for all Peers.

[0006] The second part consists of read / write shared memory, which is applicable to all Peers. Its size is defined by the R / W Section Size register and allows a size of zero.

[0007] The third part is the output section, which is mainly used for the transfer of application files. Each Peer has one, and they all have the same size. The output size of each Peer is defined by the Output Section Size register. The output section is read / write for the corresponding Peer node and read-only for all other Peers. For example, only the Peer node with ID 3 can write to the fourths output section, but all Peer nodes can read from this section. The output sections of all Peers are readable by Host Linux or Guest OS. In terms of writing, it is specific to Host Linux running as root cell for Peer0 (readable and writable), and specific to Guest OS for Peer1 to Peer(n - 1) (readable and writable).

[0008] The Jailhouse configuration information contains the configuration information of various peripherals. Among them, the memory area configuration information is an array, and each data unit in the array is the detailed information of a single (Host Linux or Guest OS) memory area configuration. The detailed configuration information of a single memory area includes: physical address, virtual address, memory size, and memory flags. Among them, the memory flags include multiple types such as whether it is readable, writable, and executable.

[0009] As the host Linux, a part of its memory area configuration is allocated as shared memory for sharing between virtual machines (Guest OS) or between a virtual machine and the host. As a virtual machine, the Guest OS's memory area configuration includes access rights and paths to the shared memory. In a virtualized environment, each Guest OS has its own memory area, and these memory areas are isolated from each other. Ivshmem allows the Guest OS to access the shared memory area through a PCI device, thus achieving memory sharing between virtual machines. PCI devices are usually used to establish communication and resource sharing channels between the host and virtual machines or between virtual machines. In the Jailhouse configuration, attributes such as the starting address and size of the memory area need to match the PCI configuration of ivshmem. Summary of the Invention

[0010] To overcome the above defects, the present invention is proposed to provide a solution to the technical problem that in the Jailhouse scenario, when there are multiple Guest OSs, it is inconvenient to obtain the running status information of the Guest OSs based on traditional physical serial ports or physical network ports.

[0011] The present invention provides a method for obtaining the running status information of a Guest OS under Jailhouse, including the following steps: Step S1: On the ivshmem memory communication model, a Trace area is newly added for each Guest OS. The Trace area includes a conf area and a running status area. The conf area is readable and writable for the Host Linux running on the Root Cell and the Guest OS running on the corresponding Cell, and is not readable and writable for the Guest OSs running on other Cells. The running status area is read-only for the Host Linux running on the Root Cell, write-only for the Guest OS running on the corresponding Cell, and is not readable and writable for the Guest OSs running on other Cells. Step S2: After the Host Linux starts successfully, run ivshmem that supports the Trace area and load the default Trace configuration information. Before the Host Linux starts the Guest OS, write the system running status information of the Guest OS to be viewed into the conf area of the corresponding Trace area. Step S3: After the Guest OS is powered on, read the configuration information of the default Trace area to obtain the corresponding Trace area address. Step S4: The Guest OS reads the system running status information of the Guest OS to be viewed by the Host Linux in S2 according to the Trace area address, and writes the corresponding running status information into the running status area of the Trace area in a certain format. Step S5: The Host Linux periodically reads the running status information of each Guest OS corresponding to each Trace area and parses and displays it to the user.

[0012] Furthermore, the system running status information of the Guest OS to be viewed includes system running time, RTOS kernel version, clock frequency, memory information, thread information, semaphore information, event information, mutex information, and message queue information.

[0013] Furthermore, the default Trace configuration information includes the Trace Base address, the total length of the Trace area, and the length of the Trace configuration information.

[0014] Furthermore, step S1 also includes correspondingly changing the memory area configuration information and virtual PCI configuration information of the Host Linux and all Guest OSs.

[0015] Furthermore, changing the memory area configuration information of the Guest OS and the Host Linux includes the steps of: Adding Trace areas with the same number as the Guest OSs to be monitored. The size and division method of each Trace area are statically configured. Before startup, the sizes of the conf area and the running status area in each Trace area are adjusted according to requirements by modifying the configuration. For each Trace area, the Host Linux has read and write permissions for the conf area and read-only permissions for the running status area. For each Trace area, only the corresponding Guest OS has read and write permissions for the conf area and write-only permissions for the running status area.

[0016] Furthermore, changing the virtual PCI configuration information of the Host Linux and all Guest OSs includes the step of: adding an option of JAILHOUSE_SHMEM_PROTO_TRACE in the shmem_protocol type.

[0017] Furthermore, it also includes the steps of: In the environment of the Host Linux, the user modifies the system running status information of the Guest OS to be viewed, and then notifies the Guest OS through the interrupt mechanism of ivshmem. After the Guest OS receives the interrupt, it executes step S4 again.

[0018] Working principle and beneficial effects of the present invention: In implementing the technical solution of the present invention, on the basis of the original ivshmem memory model, a Trace area is added for each Guest OS. This area includes a conf area and a running status area, and the read and write permissions of the conf area and the running status area are configured respectively. Enable Host Linux to write the system running status information to be viewed into the conf area. The Guest OS reads the information in the conf area and writes the corresponding running status information in the corresponding running status area. By HostLinux reading the information in the running status area again, the acquisition of the running status information of multiple Guest OSs is realized. Solve the problem that in the Jailhouse scenario, when there are multiple Guest OSs, it is inconvenient to obtain the running status information of the Guest OS based on the traditional physical serial port or physical network port. Brief description of the drawings

[0019] Referring to the attached drawings, the disclosure of the present invention will become more understandable. It is easy for those skilled in the art to understand that: these drawings are only for illustrative purposes and are not intended to limit the protection scope of the present invention. In addition, similar numbers in the figures are used to represent similar components, where: Figure 1 is a schematic diagram of the existing ivshmem memory communication model; Figure 2 is a schematic diagram of the modified ivshmem memory communication model in the present invention; Figure 3 is a schematic diagram of the original Host Linux memory area configuration information in the present invention; Figure 4 is a schematic diagram of the original Guest OS1 memory area configuration information in the present invention; Figure 5 is a schematic diagram of the original virtual PCI configuration information of Host Linux and Guest OS1 in the present invention; Figure 6 is a schematic diagram of the Host Linux memory area configuration information supporting the Trace area in the present invention; Figure 7 is a schematic diagram of the Guest OS1 memory area configuration information supporting the Trace area in the present invention; Figure 8 is a schematic diagram of the virtual PCI configuration information supporting the Trace area in the present invention; Figure 9 is a flowchart showing the system running status information in the present invention; Figure 10 It is a flowchart for the system operation status information to be viewed during the modification of the present invention. Specific Embodiments

[0020] Some embodiments of the present invention will be 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 protection scope of the present invention.

[0021] A method for obtaining the running status information of the Guest OS under Jailhouse of the present invention mainly includes the following steps S1 - step S5.

[0022] Step S1: On the ivshmem memory communication model, a Trace area is newly added for each Guest OS, and the memory area configuration information and virtual PCI configuration information of the Host Linux and all Guest OSs are correspondingly changed. The schematic diagram of the modified ivshmem memory communication model is as Figure 2 shown. Each of the said Trace areas includes a conf area and a running status area. The conf area is readable and writable for the Host Linux running in the Root Cell and the Guest OS running in the Cell corresponding to this Trace area, and is not readable and writable for the Guest OSs running in other Cells; the running status area is read-only for the Host Linux running in the Root Cell, write-only for the Guest OS running in the Cell corresponding to this Trace area, and is not readable and writable for the Guest OSs running in other Cells.

[0023] In this embodiment, the newly added Trace area is different from the output section. Each Trace area is only used to obtain the running status information of the Guest OS and does not need to obtain the running status information of the Host Linux. Therefore, the peers corresponding to several Trace areas start from 1 (i.e., Figure 2 the Trace Section for peer 1 in ), and respectively correspond to different Guest OSs. Each newly added Trace area is not readable and writable for the Guest OSs running in other Cells, in order to ensure the confidentiality of Trace configuration and data.

[0024] In one embodiment, under the original ivshmem memory communication model, the specific components of the Host Linux memory area configuration information, Guest OS memory area configuration information, and virtual PCI configuration information are as described below.

[0025] Figure 3 It is a schematic diagram of the original Host Linux memory area configuration information in the present invention. Figure 4 It is a schematic diagram of the original Guest OS1 memory area configuration information in the present invention. As Figure 3-4 shown, it can be seen that: For 0x21000000~0x21001000, it is the state table, and both Host Linux and Guest OS1 only have the READ attribute. For 0x21001000~0x21005000, it is the R / W Section Size, and both Host Linux and Guest OS1 have the READ / WRITE attribute. For 0x21005000~0x2100900, it is peer0. For the host, Host Linux has the READ / WRITE attribute, and for Guest OS1, it has the READ attribute. For 0x21009000~0x2100D000, it is peer1. For the host, Host Linux has the READ attribute, and for Guest OS1, it has the READ / WRITE attribute. For 0x2100D000~0x21011000, it is peer2. For the host, Host Linux has the READ attribute, and for Guest OS1, it has the READ attribute.

[0026] Figure 5 It is a schematic diagram of the original virtual PCI configuration information of Host Linux and Guest OS1 in the present invention. As Figure 5 shown, the start of the areas of Host Linux and Guest OS1 is 0, that is, the mem_region array area starts from No. 0; for the shmem_dev_id field, the host is 0 and Guest OS1 is 1. Then, when processing in the program, Figure 3 and Figure 4The outsection area is divided according to shmem_dev_id. That is, Host Linux is peer 0, and Guest OS1 is peer 1. Among them, shmem_protocol is JAILHOUSE_SHMEM_PROTO_UNDEFINED, which is the default configuration. Among them, shmem_peers represents the number of areas, which is 3 here, so two Guest OSs can be accommodated. The memory area configuration information of Guest OS2 is similar to that of Guest OS1. However, for 0x21009000~0x2100D000, it is peer1, and Guest OS2 has the READ attribute. For 0x2100D000~0x21011000, it is peer2, and Guest OS2 has the READ / WRITE attribute. The virtual PCI configuration information of Guest OS2 is similar to that of Guest OS1. However, the shmem_dev_id of Guest OS2 is 2.

[0027] Furthermore, to support the Trace area, the memory area configuration information and virtual PCI configuration information of Host Linux and all Guest OSs are changed accordingly. The specific components after the change are described as follows. Here, for all Guest OSs, only Guest OS1 is used as an example, and the modification methods of other Guest OSs are the same as those of Guest OS1.

[0028] Figure 6 It is a schematic diagram of the memory area configuration information of Host Linux that supports the Trace area in the present invention. As Figure 6 shown, compared with Figure 3 , two new areas with a size of 64K are added to the memory area configuration information of Host Linux. According to the actual number of Guest OSs, that is, how many Guest OSs Host Linux needs to monitor, the corresponding Trace areas are added. Here, it is the same as the example Figure 3-5 provided above. Still taking two Guest OSs as an example, so there are two parts. Each part of the area is further divided into two areas. The first area is 4K (0x1000), which is used as the conf area of the Trace area, and the other is 60K, which is used as the running status area of the Trace area. For each part of the area, Host Linux has read and write permissions for the conf area and read-only permissions for the running status area.

[0029] Figure 7 It is a schematic diagram of the memory area configuration information of Guest OS1 that supports the Trace area in the present invention. As Figure 7As shown, the memory area configuration of Guest OS1 has two additional 64K regions compared to Figure 4 For the first region 0x21020000~0x21030000, in the first 4K, Guest OS1 has read and write permissions, and in the subsequent 60K, it has only write permissions. For the second region 0x21030000~0x21040000, it is set for Guest OS2, so there are no read and write permissions, and only a JAILHOUSE_MEM_ROOTSHARED attribute indicates that this region is shared by the host.

[0030] Figure 8 Figure Figure 8 is a schematic diagram of the virtual PCI configuration information for the Trace region supported in the present invention. As Figure 8 shown, on the left is the PCI configuration information of Host Linux, and on the right is the PCI configuration information of Guest OS1. The difference from Figure 5 is that the shmem_protocol type is changed to JAILHOUSE_SHMEM_PROTO_TRACE.

[0031] By changing the memory area configuration information and virtual PCI configuration information of Host Linux and all Guest OSs, Jailhouse will simulate a PCI device with the protocol type of JAILHOUSE_SHMEM_PROTO_TRACE. Both Host Linux and Guest OS can support the Trace region. Based on this, the steps for the device to read include: When Host Linux reads, by shmem_peer=n, it is determined that there are n - 1 Guest OSs in addition to itself, and finally n - 1 parts of the Trace region are obtained. For example, when reading Figure 7 after the Out section region, there are two more regions to read, and finally the n - 1 parts of the Trace regions of 0x21020000~0x21030000 and 0x21030000~0x21040000 are obtained, and the system running status information of the Guest OS to be viewed is written into the conf region, such as system running time, RTOS kernel version, clock frequency, memory information, thread information, semaphore information, event information, mutex information, message queue information, etc.; When Guest OS1 reads, according to the corresponding PCI configuration information, it is known that the shmem_dev_id assigned to itself is 1. According to this serial number, it will continue to read Figure 8The memory information of the first trace area following the Out section area in it, and read the conf information of the trace area.

[0032] When Gues OSn-1 reads, according to the corresponding PCI configuration information in the configuration, it is known that the shmem_dev_id allocated to itself is n-1. According to this serial number, it will continue to read the memory information of the (n-1)th trace area following the Out section area, and read the conf information of the trace area.

[0033] Step S2: After Host Linux starts successfully, read the ivshmem information of the supported Trace area for this Host Linux that the user has configured, and load the default Trace configuration information (Trace Base address, total length of the Trace area, length of the Trace configuration information). Before Host Linux starts Guest OS, write the system running status information of the Guest OS to be viewed, such as system running time, RTOS kernel version, clock frequency, memory information, thread information, semaphore information, event information, mutex information, message queue information, etc. into the conf area of the corresponding Trace area.

[0034] Step S3: After Guest OS is powered on, read the ivshmem information of the supported Trace area for this Guest OS that the user has configured, and obtain the configuration information of the Trace area according to the information therein.

[0035] Step S4: Guest OS reads the system running status information of the GuestOS to be viewed by Host Linux in Step S2 according to the Trace area address, and writes the corresponding running status information into the running status area of the Trace area in a certain format, such as system running time, RTOS kernel version, clock frequency, memory information, thread information, semaphore information, event information, mutex information, message queue information, etc.

[0036] Step S5 Figure 9 is the flowchart of the system running status information displayed by the present invention. As Figure 9 shown, Host Linux periodically reads the running status information of each Guest OS corresponding to each Trace area, and parses and displays it to the user.

[0037] Furthermore Figure 10 is the flowchart of modifying the system running status information to be viewed by the present invention. As Figure 10 shown, during operation, modifying the system running status information to be viewed includes the following steps: In the Host Linux environment, the user modifies the system running status information of the Guest OS to be viewed and then notifies the Guest OS through the interrupt mechanism of ivshmem. Among them, the interrupt notification is the existing communication mechanism in ivshmem. When Host Linux wants to send an interrupt to the Guest OS, first the Guest OS registers an interrupt of an interrupt number. For example, if it registers an interrupt of number 95, Host Linux will call a certain interface of ivshmem, which will trigger the 95th interrupt. After the Guest OS receives this interrupt, it will then perform the next operation, that is, obtain information from the memory.

[0038] After the Guest OS receives the interrupt, it executes step S4 again, reads the system running status information of the Guest OS to be viewed again, and stores the system running status information in the running status information area in the Trace area according to the new information.

[0039] Based on the above steps, a Trace area is added for each Guest OS on the basis of the original ivshmem memory model. This area includes a conf area and a running status area, and the read and write permissions of the conf area and the running status area are configured respectively. Enable Host Linux to write the system running status information to be viewed to the conf area. The Guest OS reads the information in the conf area and writes the corresponding running status information in the corresponding running status area. By Host Linux reading the information in the running status area again, the acquisition of the running status information of multiple Guest OSs is realized. Solve the problem that in the Jailhouse scenario, when there are multiple Guest OSs, it is inconvenient to obtain the running status information of the Guest OS due to the traditional physical serial port or physical network port.

[0040] It should be noted that although the above steps are described in a specific order in the above embodiments, those skilled in the art can understand that in order to achieve the effects of the present invention, different steps do not necessarily have to be executed in such an order. They can be executed simultaneously (in parallel) or in other orders, and these changes are all within the protection scope of the present invention.

[0041] So far, the technical solution of the present invention has been described in combination with the preferred embodiments shown in the drawings. However, it is easy for those skilled in the art to understand that the protection scope of the present invention is obviously not limited to these specific embodiments. Without departing from the principle of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the protection scope of the present invention.

Claims

1. A method for obtaining Guest OS running status information in Jailhouse, characterized in that: The following steps are involved: Step S1, in the ivshmem memory communication model, a Trace area is added for each Guest OS, the Trace area includes a conf area and a running status area, the conf area is readable and writable for the Host Linux running on the Root Cell and the Guest OS running on the corresponding Cell, and is not readable and writable for the Guest OS running on other Cells; the running status area is read-only for the Host Linux running on the Root Cell, is write-only for the Guest OS running on the corresponding Cell, and is not readable and writable for the Guest OS running on other Cells; Step S2: After the Host Linux is successfully started, ivshmem supporting the Trace area is run to load the default Trace configuration information. Before the Host Linux starts the Guest OS, the system running status information of the Guest OS to be checked is written in the conf area corresponding to the Trace area. Step S3: After the Guest OS is powered on, it reads the configuration information of the default Trace area and obtains the corresponding Trace area address; Step S4, the Guest OS reads the system running status information of the Guest OS that the Host Linux wants to view in S2 according to the Trace area address, and writes the corresponding running status information into the running status area of ​​the Trace area in a certain format; Step S5: Host Linux periodically reads the running status information of each Guest OS corresponding to each Trace area, and parses and displays it to the user.

2. The method for obtaining Guest OS running status information in Jailhouse according to claim 1, characterized in that: The system operation status information of the Guest OS to be checked includes system operation time, RTOS kernel version, clock frequency, memory information, thread information, semaphore information, event information, mutex information, and message queue information.

3. The method for obtaining Guest OS running status information in Jailhouse according to claim 1, characterized in that: The default trace configuration information includes the trace base address, the total length of the trace area, and the length of the trace configuration information.

4. The method for obtaining Guest OS running status information in Jailhouse according to claim 1, characterized in that: The step S1 also includes correspondingly changing the memory area configuration information and virtual PCI configuration information of the Host Linux and all Guest OSs.

5. The method for obtaining Guest OS running status information in Jailhouse according to claim 4, characterized in that: Changing the memory area configuration information of the Guest OS and the memory area configuration information of the Host Linux includes the following steps: Add the same number of Trace areas as the Guest OS to be monitored. The size and division method of each Trace area are statically configured. Before startup, adjust the size of the conf area and the running status area in each Trace area by modifying the configuration as needed. For each Trace area, Host Linux has read and write permissions for the conf area and read-only permissions for the running status area. For each Trace area, only the corresponding Guest OS has read and write permissions for the conf area and write-only permissions for the running status area.

6. The method for obtaining Guest OS running status information in Jailhouse according to claim 4, characterized in that: Changing the virtual PCI configuration information of Host Linux and all Guest OSes includes the following steps: Adding a new option of JAILHOUSE_SHMEM_PROTO_TRACE in the shmem_protocol type.

7. The method for obtaining Guest OS running status information in Jailhouse according to claim 1, characterized in that: Also includes the steps: In the Host Linux environment, the user modifies the system running status information of the Guest OS to be viewed, and then notifies the Guest OS through the interrupt mechanism of ivshmem; After receiving the interrupt, the Guest OS executes step S4 again.

Images