VTCM equipment virtualization optimization method and system, terminal and medium

Abstract

The invention discloses a vTCM equipment virtualization optimization method and system, a terminal and a medium, and relates to the technical field of trusted computing, and the technical scheme is characterized in that virtiovtcmdev virtual equipment is created in a Qemu module; a drive module composed of a virtio drive and a vtcmguest drive is deployed in a Guest kernel mode; a driving module composed of a vhost module and a vtcmhost module is deployed in a Host kernel mode; a multi-queue virtio channel is designed, each vTCM instance supports multiple independent virtio queues, independent interrupt vectors are bound, and remote attestation requests are processed in parallel through multiple queues. According to the method, the context switching and memory copying overhead in traditional virtualization can be reduced, and the concurrence bottleneck of Qemu user state serial simulation is broken through.

Description

Technical Field

[0001] This invention relates to the field of trusted computing technology, and more specifically, to a vTCM device virtualization optimization method, system, terminal, and medium. Background Technology

[0002] Trusted computing technology, by introducing hardware-level security modules (such as TCM devices), provides computing systems with guarantees for identity trust, data confidentiality, and integrity, and is widely used in security-sensitive fields such as cloud computing, fintech, and the industrial internet. In virtualization scenarios, to enable virtual machines to have trusted computing capabilities, the physical TCM device needs to be virtualized into multiple vTCM instances for different VMs to share.

[0003] Traditional TCM device virtualization relies on Qemu user-space emulation: I / O operations on vTCM devices within the VM require multiple steps, including Guest OS system calls, Hypervisor trapping, Qemu user-space emulation parsing, and physical TCM device access. This process suffers from the following key problems: 1) The call chain is lengthy, with operations such as VM Exit, VM Entry, kernel-user context switching, and memory copying being time-consuming, resulting in low vTCM device I / O efficiency and failing to meet the performance requirements of high-security applications; 2) Qemu user-space emulation is a serial processing mechanism, which struggles to handle a large number of concurrent proof requests from clients when the VM based on the vTCM device acts as a remote proof server, limiting concurrent processing capabilities; 3) The physical TCM device has low resource utilization, and traditional virtualization solutions cannot achieve dynamic scheduling and efficient sharing of hardware resources.

[0004] Therefore, researching and designing a vTCM device virtualization optimization method, system, terminal, and medium that can overcome the above-mentioned defects is an urgent problem that we need to solve. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the present invention aims to provide a vTCM device virtualization optimization method, system, terminal, and medium. Based on a virtio channel-based vTCM device semi-virtualization architecture, the vTCM backend driver is offloaded to the Host kernel state, allowing the virtio device and Hypervisor to coexist in the kernel state, reducing context switching and memory copy overhead in traditional virtualization. Furthermore, a multi-queue virtio communication mechanism is designed to process remote proof requests in parallel through multiple independent virtio queues, overcoming the concurrency bottleneck of Qemu user-space serial simulation.

[0006] The above-mentioned technical objective of the present invention is achieved through the following technical solution: Firstly, a method for optimizing vTCM device virtualization is provided, including the following steps: The Qemu module creates a virtio_vtcm_dev virtual device as the basis for vTCM instantiation. The Qemu module supports configuring the number of vTCM instances. Deploy a driver module consisting of a virtio driver and a vtcm_guest driver in the Guest kernel space. The virtio driver is used to scan and mount the virtio_vtcm_dev virtual device to the virtio bus to complete the front-end and back-end parameter negotiation. The vtcm_guest driver provides the ability to encapsulate the security operation request of the Guest-side TCM device into a virtio format request and send it to the Host back-end through the virtio queue. A driver module consisting of a vhost module and a vtcm_host module is deployed in the Host kernel space. The vhost module manages the memory mapping and interrupt notification of the virtio queue. The vtcm_host module receives TCM device operation commands in virtio format from the Guest side through the virtio queue, parses the Guest side instructions and converts them into physical TCM device operation instructions, and encapsulates the processing results in virtio format and sends them back. The design incorporates a multi-queue virtio channel, with each vTCM instance supporting multiple independent virtio queues and binding independent interrupt vectors, enabling parallel processing of remote proof requests across multiple queues.

[0007] Furthermore, the Qemu module is configured as follows: The front-end and back-end negotiation process is transformed into ioctl calls to the back-end device files, enabling efficient interaction of device functionalities, queue configurations, and security parameters.

[0008] Furthermore, the Qemu module is configured as follows: Maintain the dynamic mapping relationship between vTCM instances and physical TCM devices, and support dynamic allocation of hardware resources.

[0009] Furthermore, the virtio driver is configured to perform the following operations: Scan the virtual device virtio_vtcm_dev registered by the Qemu module and mount it to the virtio bus; Receive the negotiation request from the vtcm_guest driver to confirm the number, depth, and list of supported security algorithms for the virtio queue; After the negotiation is completed, set the device status to "initialization complete".

[0010] Furthermore, the vtcm_guest driver is configured to perform the following operations: As a virtio bus matching driver, it is bound to the virtio_vtcm_dev virtual device; Provide the Guest OS with a standard TCM interface that includes one or more of the following: key management, hash calculation, and signature verification; The security operation request is encapsulated as a command in virtio format and sent through a queue. The results returned by the backend are received and parsed.

[0011] Furthermore, the vtcm_host module is configured to perform the following operations: The communication link with the physical TCM device is initialized by receiving the negotiation parameters forwarded by the Qemu module through an ioctl call. The Guest-side virtio commands are analyzed to be recognizable operation commands by the physical TCM. The physical TCM processing results are encapsulated in virtio format and sent back. It supports parallel processing of multiple queues, and assigns an independent operation context to each queue.

[0012] Furthermore, each of the virtio queues contains an independent desc-table, available-ring, used-ring, and index identifier, wherein the index identifier consists of last_used_idx and last_avail_idx; The desc-table records descriptor information, the available-ring stores the index of available descriptors, the used-ring stores the index of used descriptors, and the last_used_idx and last_avail_idx record the tail indices of used and available descriptors, respectively. Each queue implements parallel notification through an independent interrupt vector.

[0013] Secondly, a vTCM device virtualization optimization system is provided, including: The Qemu module is used to create the virtio_vtcm_dev virtual device, which serves as the basis for vTCM instantiation and supports configuring the number of vTCM instances. The Guest kernel-mode driver module consists of the virtio driver and the vtcm_guest driver. The virtio driver is used to scan and mount the virtio_vtcm_dev virtual device to the virtio bus to complete the front-end and back-end parameter negotiation. The vtcm_guest driver provides the ability to encapsulate the security operation request of the Guest-side TCM device into a virtio format request and send it to the Host back-end through the virtio queue. The Host kernel-mode driver module consists of the vhost module and the vtcm_host module. The vhost module manages the memory mapping and interrupt notification of the virtio queue. The vtcm_host module receives TCM device operation commands in virtio format from the Guest side through the virtio queue, parses the Guest side instructions and converts them into physical TCM device operation instructions, and encapsulates the processing results in virtio format and sends them back. Multi-queue virtio channels support multiple independent virtio queues for each vTCM instance and bind independent interrupt vectors to process remote proof requests in parallel through multiple queues.

[0014] Thirdly, a computer terminal is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a vTCM device virtualization optimization method as described in any one of the first aspects.

[0015] Fourthly, a computer-readable medium is provided having a computer program stored thereon, the computer program being executed by a processor to implement a vTCM device virtualization optimization method as described in any one of the first aspects.

[0016] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention provides a virtualization optimization method for vTCM devices. Based on a virtio channel-based semi-virtualized architecture for vTCM devices, the method unloads the vTCM backend driver to the host kernel mode, allowing the virtio device and the hypervisor to coexist in the kernel mode, thereby reducing the context switching and memory copy overhead in traditional virtualization. In addition, a multi-queue virtio communication mechanism is designed to process remote proof requests in parallel through multiple independent virtio queues, breaking through the concurrency bottleneck of serial simulation in Qemu user mode. 2. This invention achieves secure isolation and efficient mapping between Guest-side VTCM instances and physical TCM devices, improving device virtualization efficiency while ensuring core security functions such as key isolation and operation auditing. 3. This invention adapts to the business characteristics of remote authentication services, optimizes the virtio queue scheduling strategy and secure command transmission format, and achieves low latency and high throughput in request processing. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of embodiments of the invention and form part of this application, do not constitute a limitation thereof. In the drawings: Figure 1This is a flowchart from Embodiment 1 of the present invention; Figure 2 This is the overall architecture diagram implemented in Embodiment 1 of the present invention; Figure 3 This is a system block diagram in Embodiment 2 of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of the present invention are only used to explain the present invention and are not intended to limit the present invention.

[0019] vTCM: Virtual Trusted Cryptography Module; Qemu: An open-source virtual machine monitor (Quick Emulator). virtio: A semi-virtualized I / O device standard; Guest: refers to a virtual machine (Guest Machine), which is a virtual client running on the host machine.

[0020] Host: refers to the host machine; VM: Virtual Machine, a synonym for Guest; Hypervisor: Virtual machine monitor; KVM: Kernel-based Virtual Machine; virtio_vtcm_dev: A type of virtual TCM device based on the virtio framework; vtcm_guest: The kernel driver module on the Guest side; vtcm_host: The kernel driver module on the host side; vhost: A kernel module (vhost driver); TCM: Trusted Cryptography Module; misc: Miscellaneous Device; file_operations: A core structure in the Linux kernel used to define the interface between character device drivers and user space; chardev: Character Device; PCI: Peripheral Component Interconnect standard; ioctl: Input / output control system call; I / O: Input / Output; desc-table: Descriptor Table; avail-ring: Available Ring; used-ring: The used descriptor ring; last_used_idx: Last Used Index; last_avail_idx: Last Available Index; SM2: A Chinese cryptographic algorithm standard; SHA-256: Secure Hash Algorithm 256-bit; ko: Kernel object file; insmod: The command to insert a module. echo: Linux command; multi_queue: Parameter for multiple queues; id: Identifier; queues: The number of queues; path: Path parameter; name: Name parameter; port: Port parameter; bus: bus; status: Status indicator; socket: a type of socket; OS: Operating System.

[0021] Example 1: A vTCM device virtualization optimization method, such as Figure 1 As shown, this is achieved through the following steps.

[0022] Step 1: Create the virtio_vtcm_dev virtual device in the Qemu module.

[0023] The Qemu module creates the virtio_vtcm_dev virtual device as the basis for vTCM instantiation. The Qemu module supports configuring the number of vTCM instances.

[0024] The virtual device `virtio_vtcm_dev` created in the Qemu module is a Virtio device type at the same level as `virtio_net_dev`, and it forms the basis for vTCM instantiation and Virtio channel establishment. In this framework, the Guest OS side driver is the front end, and the Host OS side driver is the back end, with the back end being unloaded to the Host kernel mode. Figure 2 As shown.

[0025] Specifically, the core functionality of the Qemu module is as follows: 1) Register the virtio_vtcm_dev virtual device type, which supports configuring parameters such as the number of vTCM instances and the number of virtio queues per instance when the Qemu module starts; 2) Convert the negotiation process between the Guest frontend and backend (such as device functional characteristics, queue configuration, and security parameters) into kernel-mode ioctl calls to achieve efficient interaction of information between the frontend and backend and avoid Qemu user-mode relay; 3) Maintain the mapping relationship between vTCM instances and physical TCM devices to support dynamic allocation of hardware resources.

[0026] Step 2: Deploy the driver module consisting of the virtio driver and the vtcm_guest driver in the Guest kernel space.

[0027] The native virtio driver is responsible for front-end communication with the virtio_vtcm_dev virtual device, while the vtcm_guest driver provides the security function interface for the vTCM device. Specifically, the virtio driver scans for and mounts the virtio_vtcm_dev virtual device to the virtio bus, completing front-end and back-end parameter negotiation; the vtcm_guest driver provides the ability to encapsulate security operation requests from the Guest-side TCM device into virtio format requests and send them to the Host back-end via a virtio queue.

[0028] Specifically, the core functions of the virtio driver are: scanning the virtio_vtcm_dev virtual devices registered by the Qemu module and mounting them to the virtio bus; receiving negotiation requests from the vtcm_guest driver and confirming parameters such as the number of virtio queues, queue depth, and list of supported security algorithms; and setting the status of the virtio_vtcm_dev virtual device after negotiation, marking the completion of vTCM instance initialization.

[0029] Specifically, the core functions of the vtcm_guest driver configuration are: to act as a matching driver on the virtio bus and bind to the virtio_vtcm_dev virtual device; to provide the Guest OS with standard TCM device interfaces, such as key management, hash calculation, and signature verification; to encapsulate the Guest's security operation requests into virtio format instructions and send them to the Host backend through the virtio queue, while simultaneously receiving the processing results returned by the backend.

[0030] Step 3: Deploy the driver module consisting of the vhost module and the vtcm_host module in the Host kernel space.

[0031] The Host kernel-mode driver consists of the vtcm_host module and the vhost module. As the offloading backend for the virtio_vtcm_dev virtual device, it interacts directly with the physical TCM device to achieve efficient processing of secure operations.

[0032] Specifically, the core functions of the vhost module are: to provide kernel-mode transmission capabilities for the virtio channel, to manage memory mapping and interrupt notifications for the virtio queue, and to reduce the overhead of switching between kernel mode and user mode.

[0033] Specifically, the core functions of the vtcm_host module are: to receive front-end and back-end negotiation parameters forwarded by the Qemu module via ioctl calls, and to initialize the communication link with the physical TCM device; to receive virtio format security commands sent by the Guest front-end, parse them, and convert them into operation commands that the physical TCM device can recognize; to encapsulate the processing results of the physical TCM device (such as signature data and verification results) into virtio format and send them back to the Guest front-end through a virtio queue; and to support parallel processing of multiple queues, allocating an independent TCM device operation context to each virtio queue to improve concurrency performance.

[0034] Step 4: Design a multi-queue virtio channel. Each vTCM instance supports multiple independent virtio queues and binds them to independent interrupt vectors to process remote proof requests in parallel through multiple queues.

[0035] It should be noted that the number of virtio queues supported by each vTCM instance can be dynamically adjusted based on the performance of the physical TCM device.

[0036] Each virtio queue contains an independent descriptor table, available ring, used ring, and index identifier, which consists of last_used_idx and last_avail_idx.

[0037] Specifically, the desc-table records descriptor information, the available-ring stores the index of available descriptors, the used-ring stores the index of used descriptors, and the last_used_idx and last_avail_idx record the tail indices of used and available descriptors, respectively. Each queue implements parallel notification through an independent interrupt vector.

[0038] Taking a TCM device as an example, the specific steps for deploying a vTCM device and providing remote authentication services using virtio semi-virtualization technology are as follows: 1) Host-side driver development and deployment: Register the misc device in the vtcm_host.ko source code, with the device node being " / dev / vtcm", and implement the open, release, ioctl, and other functions in the file_operations structure for interaction with Qemu and physical TCM devices.

[0039] Compile the vtcm_host.ko driver module and the vhost.ko driver module, and load them into the Host kernel using the insmod command, specifying the bus address and interrupt number of the physical TCM device during loading.

[0040] Configure the Host kernel parameters to enable virtio multi-queue support (echo "Y"> / sys / module / vhost / parameters / multi_queue).

[0041] 2) Qemu startup and modification: Write the source code for the virtio_vtcm_dev virtual device type to implement functions such as device initialization, front-end / back-end negotiation, and queue management. Add the source code to the " / hw / virtio / " path in the Qemu source code.

[0042] Modify the Qemu configuration file to enable virtio_vtcm_dev virtual device support, and recompile Qemu to generate binary files.

[0043] Write a Qemu startup script, specify the virtio_vtcm_dev virtual device parameter, and use the following example startup command: qemu-system-x86_64-enable-kvm-device virtio_vtcm_dev,id=vtcm0,queues=8 \ -chardev socket,path= / var / run / vtcm.sock,id=vtcm_chr0 \ -device virtio-serial-pci \ -device virtserialport,chardev=vtcm_chr0,name=vtcm.port0.

[0044] 3) Guest-side driver deployment and configuration: In GuestOS, compile the native virtio.ko driver and load it using the insmod command. The driver automatically scans and discovers the virtio_vtcm_dev virtual device in Qemu and mounts it to the virtio bus.

[0045] Compile the vtcm_guest.ko driver module, load it, and use it as the matching driver on the virtio bus to bind with the virtio_vtcm_dev virtual device.

[0046] Driver negotiation: The vtcm_guest driver and the host backend negotiate the list of security features (such as support for SM2 key generation and SHA-256 hash calculation), queue configuration and other parameters through ioctl calls, and complete the creation of the virtio queue.

[0047] 4) Deployment of remote authentication service: Deploy a remote authentication server program in the Guest OS. This program calls the security functions of the vTCM instance through the standard TCM device interface to implement services such as client authentication and configuration integrity verification.

[0048] The server program uses a multi-threaded mechanism, with each thread bound to a virtio queue to independently handle client proof requests.

[0049] The client sends a verification request to the server over the network, and the server completes the security verification through the vTCM instance and returns the result.

[0050] Example 2: A vTCM device virtualization optimization system, which implements a vTCM device virtualization optimization method described in Example 1, such as... Figure 2 and Figure 3 As shown, it includes the Qemu module, the Guest kernel-mode driver module, the Host kernel-mode driver module, and a multi-queue virtio channel.

[0051] The Qemu module is used to create the virtio_vtcm_dev virtual device, which serves as the basis for vTCM instantiation and supports configuring the number of vTCM instances. The Guest kernel-mode driver module consists of the virtio driver and the vtcm_guest driver. The virtio driver scans and mounts the virtio_vtcm_dev virtual device to the virtio bus, completing front-end and back-end parameter negotiation. The vtcm_guest driver provides the ability to encapsulate security operation requests from the Guest-side TCM device into virtio format requests and send them to the Host back-end via a virtio queue. The Host kernel-mode driver module consists of the vhost module and the vtcm_host module. The vhost module manages the memory mapping and interrupt notification of the virtio queue. The vtcm_host module receives TCM device operation commands in virtio format from the Guest side through the virtio queue, parses the Guest side instructions and converts them into physical TCM device operation instructions, and encapsulates the processing results in virtio format for transmission back. The multi-queue virtio channel supports multiple independent virtio queues for each vTCM instance and binds them to independent interrupt vectors, enabling parallel processing of remote proof requests through multiple queues.

[0052] Example 3: A computer terminal includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements a vTCM device virtualization optimization method as described in Example 1.

[0053] Example 4: A computer-readable medium having a computer program stored thereon, the computer program being executed by a processor to implement a vTCM device virtualization optimization method as described in Example 1.

[0054] Working Principle: This invention utilizes a semi-virtualized architecture for vTCM devices based on virtio channels. It offloads the vTCM backend driver to the Host kernel space, allowing the virtio device and Hypervisor to coexist in the kernel space, reducing context switching and memory copy overhead in traditional virtualization. A multi-queue virtio communication mechanism is designed to process remote proof requests in parallel through multiple independent virtio queues, overcoming the concurrency bottleneck of Qemu user-space serial simulation. It achieves secure isolation and efficient mapping between Guest-side vTCM instances and physical TCM devices, improving device virtualization efficiency while ensuring core security functions such as key isolation and operation auditing. Adapting to the business characteristics of remote proof services, it optimizes virtio queue scheduling strategies and secure command transmission formats, achieving low latency and high throughput in request processing.

[0055] In this invention, the I / O latency of the VTCM device is significantly reduced compared to the traditional QEMU simulation scheme, and the data processing throughput is increased by 2-3 times, meeting the performance requirements of high-security applications. Based on a multi-queue design, the concurrent request processing capability of the remote proof server is improved, supporting simultaneous access by thousands of clients, making it suitable for large-scale cloud computing scenarios. Dynamic sharing of physical TCM device resources is achieved, improving hardware utilization compared to traditional solutions and reducing the hardware cost of virtualization deployment. The VTCM instance is fully compatible with the interface specifications and security functions of the physical TCM device, allowing migration without modifying the upper-layer application, and possesses good compatibility and scalability.

[0056] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0057] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0058] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0059] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0060] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A vTCM device virtualization optimization method, characterized in that, Includes the following steps: The Qemu module creates a virtio_vtcm_dev virtual device as the basis for vTCM instantiation. The Qemu module supports configuring the number of vTCM instances. Deploy a driver module consisting of a virtio driver and a vtcm_guest driver in the Guest kernel space. The virtio driver is used to scan and mount the virtio_vtcm_dev virtual device to the virtio bus to complete the front-end and back-end parameter negotiation. The vtcm_guest driver provides the ability to encapsulate the security operation request of the Guest-side TCM device into a virtio format request and send it to the Host back-end through the virtio queue. A driver module consisting of a vhost module and a vtcm_host module is deployed in the Host kernel space. The vhost module manages the memory mapping and interrupt notification of the virtio queue. The vtcm_host module receives TCM device operation commands in virtio format from the Guest side through the virtio queue, parses the Guest side instructions and converts them into physical TCM device operation instructions, and encapsulates the processing results in virtio format and sends them back. The design incorporates a multi-queue virtio channel, with each vTCM instance supporting multiple independent virtio queues and binding independent interrupt vectors, enabling parallel processing of remote proof requests across multiple queues.

2. The vTCM device virtualization optimization method according to claim 1, characterized in that, The Qemu module is configured as follows: The front-end and back-end negotiation process is transformed into ioctl calls to the back-end device files, enabling efficient interaction of device functionalities, queue configurations, and security parameters.

3. The vTCM device virtualization optimization method according to claim 1, characterized in that, The Qemu module is configured as follows: Maintain the dynamic mapping relationship between vTCM instances and physical TCM devices, and support dynamic allocation of hardware resources.

4. The vTCM device virtualization optimization method according to claim 1, characterized in that, The virtio driver is configured to perform the following operations: Scan the virtual device virtio_vtcm_dev registered by the Qemu module and mount it to the virtio bus; Receive the negotiation request from the vtcm_guest driver to confirm the number, depth, and list of supported security algorithms for the virtio queue; After the negotiation is completed, set the device status to "initialization complete".

5. The vTCM device virtualization optimization method according to claim 1, characterized in that, The vtcm_guest driver is configured to perform the following operations: As a virtio bus matching driver, it is bound to the virtio_vtcm_dev virtual device; Provide the Guest OS with a standard TCM interface that includes one or more of the following: key management, hash calculation, and signature verification; The security operation request is encapsulated as a command in virtio format and sent through a queue. The results returned by the backend are received and parsed.

6. The vTCM device virtualization optimization method according to claim 1, characterized in that, The vtcm_host module is configured to perform the following operations: The communication link with the physical TCM device is initialized by receiving the negotiation parameters forwarded by the Qemu module through an ioctl call. The Guest-side virtio commands are analyzed to be recognizable operation commands by the physical TCM. The physical TCM processing results are encapsulated in virtio format and sent back. It supports parallel processing of multiple queues, and assigns an independent operation context to each queue.

7. The vTCM device virtualization optimization method according to claim 1, characterized in that, Each virtio queue contains an independent desc-table, available-ring, used-ring, and index identifier, wherein the index identifier consists of last_used_idx and last_avail_idx; The desc-table records descriptor information, the available-ring stores the index of available descriptors, the used-ring stores the index of used descriptors, and the last_used_idx and last_avail_idx record the tail indices of used and available descriptors, respectively. Each queue implements parallel notification through an independent interrupt vector.

8. A vTCM device virtualization optimization system, characterized in that, include: The Qemu module is used to create the virtio_vtcm_dev virtual device, which serves as the basis for vTCM instantiation and supports configuring the number of vTCM instances. The Guest kernel-mode driver module consists of the virtio driver and the vtcm_guest driver. The virtio driver is used to scan and mount the virtio_vtcm_dev virtual device to the virtio bus to complete the front-end and back-end parameter negotiation. The vtcm_guest driver provides the ability to encapsulate the security operation request of the Guest-side TCM device into a virtio format request and send it to the Host back-end through the virtio queue. The Host kernel-mode driver module consists of the vhost module and the vtcm_host module. The vhost module manages the memory mapping and interrupt notification of the virtio queue. The vtcm_host module receives TCM device operation commands in virtio format from the Guest side through the virtio queue, parses the Guest side instructions and converts them into physical TCM device operation instructions, and encapsulates the processing results in virtio format and sends them back. Multi-queue virtio channels support multiple independent virtio queues for each vTCM instance and bind independent interrupt vectors to process remote proof requests in parallel through multiple queues.

9. A computer terminal, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements a vTCM device virtualization optimization method as described in any one of claims 1-7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, The computer program, when executed by a processor, can implement a vTCM device virtualization optimization method as described in any one of claims 1-7.

Images