Method and device for developing partition management program and electronic equipment

Abstract

The invention discloses a partition management program development method and device and electronic equipment, and belongs to the technical field of intelligent automobiles. The method specifically comprises the following steps: generating a register semantic structure of a chip according to register description data of the chip and behavior specification data of the chip; determining a virtual register structure corresponding to the virtual machine in the partition strategy data according to the register semantic structure; determining a target strategy matched with the architecture configuration data of the chip according to the partition strategy data; generating an intermediate representation structure according to the register semantic structure, the virtual register structure and a binding relationship between the target strategy and nodes in the register semantic structure; the intermediate representation structure is used for representing hardware resources allocated for the virtual machine, and permissions and time sequences corresponding to the hardware resources; and compiling the intermediate representation structure into a target file loaded by a machine. According to the method, the manpower cost of partition management program development can be reduced, and the adaptation capability of partition management program development can be improved.

Description

Technical Field

[0001] This application belongs to the field of intelligent vehicle technology, specifically relating to a method, apparatus, and electronic device for developing a partition management program. Background Technology

[0002] With the development of intelligent vehicle technology, vehicle functions are becoming increasingly diverse. Hybrid critical in-vehicle systems can support multiple functions such as driving control and infotainment on a single hardware platform. To achieve strong isolation and deterministic parallel operation between different functions, the partitioning management program divides the system's hardware resource space into different functional partitions based on the safety level and real-time requirements of each function before the hybrid critical in-vehicle system starts. These hardware resources can include: CPU, memory, MMIO (Memory-Mapped Input / Output), IRQ (Interrupt Request Queue), etc. For example, high-performance CPU cores, high-speed memory blocks, dedicated MMIO address spaces, and independent IRQ interrupt channels are allocated to the driving control functional partition to achieve hard real-time response to driving commands; while the infotainment functional partition is configured with relatively independent general-purpose CPU cores, shared memory pools, non-exclusive MMIO resources, and dedicated IRQ interrupt channels to meet the needs of multimedia playback, navigation interaction, etc. Through this static partitioning mechanism, different functional partitions can operate stably on the same hardware platform without interference, improving both hardware resource utilization and driving safety.

[0003] Currently, the development of partition management programs heavily relies on manual configuration by engineers. Specifically, engineers manually write partition configuration files and device tree source files based on the hardware resource information contained in the hardware platform chip's datasheet. The partition configuration file defines the allocation scheme of hardware resources such as CPU cores, memory address ranges, and MMIO space segments for each functional partition; the device tree source file describes the hardware platform's composition, device connection relationships, and resource attributes using a standardized data structure.

[0004] However, this development model, which relies heavily on manual labor, requires significant manpower. Furthermore, the hardware resource allocation rules set in the partition configuration file are closely linked to the hardware resources of the hardware platform. When dealing with different hardware platforms, adjusting these allocation rules is difficult due to the differences in hardware resources across platforms. The device tree source file itself describes the hardware resource layout and other information for a specific hardware platform, and is also strongly correlated with hardware resources. It requires corresponding adjustments during cross-platform adaptation, further increasing the complexity of cross-hardware platform adaptation. Summary of the Invention

[0005] The purpose of this application is to provide a method, apparatus, and electronic device for developing a partition management program, which can reduce the human resource cost of developing a partition management program and improve the adaptability of the partition management program development.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a method for developing a partition management program. The method includes: acquiring input data; the input data includes: chip register description data, chip behavior specification data, chip architecture configuration data, and partition policy data; generating a register semantic structure of the chip based on the chip register description data and chip behavior specification data; determining a virtual register structure corresponding to the virtual machine in the partition policy data based on the register semantic structure; determining a target policy matching the chip architecture configuration data based on the partition policy data; generating an intermediate representation structure by compiling the intermediate representation structure into a machine-loaded target file binding relationship based on the register semantic structure, the virtual register structure, and the partition policy data; the intermediate representation structure is used to represent hardware resources allocated to the virtual machine, the permissions and timings corresponding to the hardware resources; compiling the intermediate representation structure into a machine-loaded target file; the target file is a configuration file of the partition management program, or the target file is a component of the executable file of the partition management program, and the target file follows the configuration rules of the partition management program.

[0007] Secondly, embodiments of this application provide a development apparatus for a partition management program. The apparatus includes: a receiving module for acquiring input data; the input data includes: chip register description data, chip behavior specification data, chip architecture configuration data, and partitioning strategy data; a semantic structure generation module for generating a register semantic structure of the chip based on the chip register description data and chip behavior specification data; a virtual structure generation module for determining a virtual register structure corresponding to the virtual machine in the partitioning strategy data based on the register semantic structure; a strategy determination module for determining a target strategy that matches the chip architecture configuration data based on the partitioning strategy data; an intermediate structure generation module for generating an intermediate representation structure based on the register semantic structure, the virtual register structure, and the binding relationship between the target strategy and nodes in the register semantic structure; the intermediate representation structure represents hardware resources allocated to the virtual machine, the permissions and timing corresponding to the hardware resources; and a compilation module for compiling the intermediate representation structure into a machine-loadable target file; the target file is a configuration file of the partition management program, or the target file is a component of the executable file of the partition management program, and the target file follows the configuration rules of the partition management program.

[0008] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0009] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0010] In the technical solution of this application embodiment, the input data is automatically processed and a target file that can be directly loaded and executed by the target machine is generated. Therefore, this application embodiment can significantly reduce the manual processing steps, thereby effectively reducing the labor costs in the development process.

[0011] Furthermore, the method in this application integrates input data (including chip register description data, behavior specification data, architecture configuration data, and partitioning strategy data) into a unified intermediate data structure. Because this intermediate data structure can extract semantic information representing functional partitions based on resource, permission, and timing relationships, it can mask the underlying differences between different chips and architectures, thereby achieving accurate representation of functional partition semantics. Therefore, this application embodiment is applicable to multiple chips and architectures, and significantly improves the adaptability of partition management program development. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating the steps of developing a partition management program according to an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a virtual machine monitor according to an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a development apparatus for a partition management program according to an embodiment of this application; Figure 4 This is a structural block diagram of a development apparatus for a partition management program according to an embodiment of this application; Figure 5 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0015] The development method, apparatus, and electronic device of the partition management program provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0016] In this embodiment, the partition management program is a type of virtualization management program that partitions and isolates hardware resources during the system startup phase. This program, based on a pre-defined partitioning strategy, divides hardware resources into several independent isolated domains (i.e., functional partitions), each of which can run an independent guest operating system or bare-metal program. Due to its significant advantages such as low virtualization layer overhead, deterministic execution timing, and strong isolation, it is widely used in embedded real-time systems, industrial control, intelligent vehicles, aerospace, and other fields with extremely high requirements for security and real-time performance.

[0017] A virtual machine monitor (HV, Hypervisor) is a type of partition management program. Typical examples include Bao, Jailhouse, Dom0 - less Xen, and Hyperlaunch.

[0018] The Virtual Machine Monitor (VM) isolates and schedules multiple virtual machines (VMs) as guest systems on top of the hardware, managing CPU / memory / interrupt / device passthrough and sharing. The target files developed in this application directly serve the startup and runtime control of the HV. These target files specifically include: page tables, MPU tables (Memory Protection Unit Tables), DTBs (Device Tree Blobs), configuration JSON (JavaScript Object Notation) / C code, etc.

[0019] For example, in the context of intelligent vehicle technology, the partition management program, based on a pre-defined partitioning strategy, allocates corresponding hardware resources to the appropriate functional partitions according to the hardware performance requirements of driving control and infotainment functions. For instance, hardware resources with fast processing speeds and timely responses are allocated to the driving control functional partition to improve the timeliness and accuracy of vehicle driving control; while hardware resources focused on graphics processing and with larger storage capacity are allocated to the infotainment functional partition to meet the needs of multimedia playback, navigation map loading, and other functions.

[0020] To address the technical problems of high labor costs and difficulty in cross-platform adaptation in the development methods of partition management programs in related technologies, this application provides a method for developing a partition management program. The method specifically includes: receiving input data; the input data includes: chip register description data, chip behavior specification data, chip architecture configuration data, and partitioning strategy data; generating a register semantic structure of the chip based on the chip register description data and chip behavior specification data; determining the virtual register structure corresponding to the virtual machine in the partitioning strategy data based on the register semantic structure; determining a target strategy that matches the chip architecture configuration data based on the partitioning strategy data; generating an intermediate representation structure based on the binding relationship between the register semantic structure, the virtual register structure, the target strategy, and nodes in the register semantic structure; and compiling the intermediate representation structure into a machine-loadable target file.

[0021] The method described in this application embodiment can be executed by a development tool. Since this development tool can automatically process input data and generate target files that can be directly loaded and executed by the target machine, this application embodiment can significantly reduce manual processing steps, thereby effectively reducing labor costs during the development process.

[0022] Furthermore, the process of generating the target file in this embodiment includes: generating the register semantic structure of the chip based on the register description data and the behavior specification data of the chip; determining the virtual register structure corresponding to the virtual machine in the partitioning policy data based on the register semantic structure; determining the target policy that matches the architecture configuration data of the chip based on the partitioning policy data; generating an intermediate representation structure based on the binding relationship between the register semantic structure, the virtual register structure, the target policy, and the nodes in the register semantic structure; and compiling the intermediate representation structure into a machine-loadable target file.

[0023] The method in this application integrates input data (including chip register description data, behavior specification data, architecture configuration data, and partitioning strategy data) into a unified intermediate data structure. Because this intermediate data structure can extract semantic information representing functional partitions based on resource, permission, and timing relationships, it can mask the underlying differences between different chips and architectures, thereby achieving accurate representation of the semantics of functional partitions. Therefore, this application's embodiments are applicable to various chips and architectures, and significantly improve the adaptability of partitioning management program development.

[0024] In this embodiment of the application, the target file is a configuration file of the partition management program, or the target file is a component of the executable file of the partition management program, and the target file follows the configuration rules of the partition management program.

[0025] The target file is the configuration file of the partition management program, specifically including: platform hardware initialization function, device tree binary file, and other target files. These are parsed and loaded by the partition management program during the power-on / boot phase. Based on the target files, the partition management program creates partitions / binds CPUs, establishes memory mapping, and configures interrupt routing and DMA (Direct Memory Access) whitelists.

[0026] The target files, as components of the executable file of the partition management program, specifically include: target files containing MMU page tables and MPU region tables, which, along with the partition management program code, participate in the compilation and linking process to ultimately generate the executable file. When the partition management program starts, the contents of these target files are executed as initialization routines to perform hardware initialization operations such as loading page tables.

[0027] The configuration rules are used to configure the configuration version and linking rules of the target file. The linking rules include: fields, units, alignment constraints, and structures and symbols defined in the header file corresponding to the hardware resources.

[0028] Fields are the basic units in a configuration file used to describe information related to hardware resources. When describing various types of hardware resources, each field corresponds to a specific attribute of the hardware resource: for example, when describing memory, the "starting address" field specifies the exact location where the memory region begins, and the "size" field specifies the capacity of the memory region; when describing a CPU, the "number of cores" field specifies the number of CPU cores, and the "clock speed" field specifies the CPU's operating frequency.

[0029] Units define the standard for measuring the numerical values ​​of a field. The values ​​of different hardware resource fields need to have their physical / logical meaning clearly defined through units: for example, the unit for the "memory size" field can be bytes (Byte), megabytes (MB), etc.; the unit for the "CPU clock speed" field is usually Hertz (Hz); and the unit for the "hard disk read / write speed" field can be megabytes per second (MB / s). Clear units prevent misunderstandings of hardware resource configuration values ​​and are the foundation for the practical guidance of configuration information.

[0030] Alignment constraints are rules governing the location of hardware-related data in memory, established based on hardware architecture and performance requirements. Here, "data" refers to all information interacting with hardware resources (such as hardware register values, hardware configuration parameters, and business data read / written by the hardware). Different hardware architectures have strict requirements regarding the storage location of this type of data: the constraint stipulates that the starting memory address of specific data must be an integer multiple of its own size (for example, 4-byte hardware configuration parameters must start from addresses that are multiples of 4). Adhering to this constraint allows hardware to access data efficiently: if data is misaligned, the processor needs to perform multiple memory accesses to obtain the complete data, reducing hardware operating efficiency and even causing access errors under some strict hardware architectures.

[0031] A structure defined in a header file is a composite data type that combines multiple configuration fields related to hardware resources. In hardware control projects with multiple source files, the structure must be defined in the header file: because different source files (such as hardware initialization files and hardware data read / write files) need to operate on the same set of hardware configuration information, by simply including this header file in these source files, a unified structure can be used directly. This avoids redefining the structure in each source file and ensures that the processing logic of hardware configuration information is consistent across all source files, greatly improving code maintainability and reusability (for example, integrating the memory "starting address", "size", and "access permissions" fields into a memory configuration structure and storing it in a header file for use throughout the project).

[0032] Symbols defined in header files refer to external variables, constants, or function names declared in the header file that are related to hardware resources (such as global variables representing hardware register addresses or hardware configuration initialization function names declared externally). Symbols must be declared in header files because different source files need to operate on underlying hardware resources through these symbols (such as reading and writing hardware registers through register address symbols). Including the header file allows all source files to reference these symbols uniformly. During the linking phase, the linker precisely associates symbols with their corresponding memory addresses or function implementations. Without header files, the references to symbols by different source files would be inconsistent, making accurate manipulation of hardware resources impossible. Furthermore, object files use a unified dialect such as JSON / YAML / DTB to carry configuration.

[0033] Because the target file follows the configuration rules of the partition management program, its internal hardware resource descriptions (such as memory mappings and interrupt configurations) can match the parsing logic of the partition management program, fundamentally avoiding runtime errors caused by incompatible configuration formats. Explicit linking rules and other requirements in the configuration rules can identify configuration-level issues during the compilation and linking stages, rather than exposing them only after system startup. Furthermore, the unified field definitions, unit conventions, and structure specifications in the configuration rules mean that when switching hardware platforms, only the configuration rules need to be modified, without rewriting the main code of the partition management program, significantly improving cross-platform portability efficiency. In addition, the explicit definition of alignment requirements in the configuration rules ensures the efficiency and security of memory access, avoiding performance degradation or hardware anomalies caused by misaligned memory access.

[0034] The partition management program development method of this application embodiment can be executed by an electronic device, which specifically includes, but is not limited to: an in-vehicle computing platform, an automotive-grade controller, an industrial control host, an embedded development board, a personal computer, a server, a portable mobile terminal, and other electronic devices that have data processing capabilities and can complete chip and architecture-related data parsing and intermediate data structure construction.

[0035] The development method of the partition management program of this application will be described below through specific embodiments.

[0036] Reference Figure 1 It illustrates a flowchart of a method for developing a partition management program according to an embodiment of this application. The method specifically includes the following steps: Step 101: Obtain input data; the input data includes: chip register description data, chip behavior specification data, chip architecture configuration data, and partitioning strategy data; Step 102: Generate the register semantic structure of the chip based on the register description data and the behavior specification data of the chip; optionally, the register semantic structure includes: the node corresponding to the register or bit field, the relationship between different nodes, the constraint information corresponding to the node, and the index information of the node in the address space tree and hardware resource category; Step 103: Based on the register semantic structure, determine the virtual register structure corresponding to the virtual machine in the partitioning policy data; optionally, the virtual register structure is used to represent the virtual registers allocated to the virtual machine, the permissions and timing corresponding to the virtual registers; Step 104: Based on the partitioning strategy data, determine the target strategy that matches the architecture configuration data of the chip; Step 105: Generate an intermediate representation structure based on the register semantic structure, the virtual register structure, and the binding relationship between the target policy and the nodes in the register semantic structure; the intermediate representation structure is used to represent the hardware resources allocated to the virtual machine, the permissions and timing corresponding to the hardware resources; Optionally, the intermediate representation structure includes: a resource permission timing structure, a virtual register structure, an interrupt routing structure, a whitelist structure, and a lease directory structure; the resource permission timing structure is used to represent the hardware resources allocated to the virtual machine, the permissions and timing corresponding to the hardware resources; the whitelist structure represents the hardware resources that the virtual machine can access; and the lease directory structure represents the virtual machine's lifecycle, priority, and preemption rules for using resources. Step 106: Compile the intermediate representation structure into a machine-loadable target file.

[0037] The methods described in this application can be executed by a development tool. In the field of intelligent vehicle technology, this development tool supports virtualization development for various in-vehicle hardware platforms and can be widely used in in-vehicle embedded systems (such as high-performance computing platforms and intelligent driving platforms). This development tool is suitable for resource management and virtualization of IoT devices, enabling IoT devices to automatically adjust virtualization resource configurations according to the hardware platform. In the field of industrial control technology, this development tool can provide a unified virtualization and hardware configuration management solution for various industrial equipment, improving the flexibility and security of automated production lines.

[0038] Reference Figure 2 The diagram illustrates the structure of a virtual machine monitor according to an embodiment of this application. The virtual machine monitor specifically includes: a hardware platform adaptation layer, a register abstraction layer, a resource management layer, a scheduling and interrupt management layer, and a monitor core layer.

[0039] The hardware platform adaptation layer is the layer that interfaces with the hardware platform. Its functions include: privilege level settings: configuring the hardware's privilege level rules; memory protection mechanism: interfacing with the hardware's memory protection unit and other protection logic; CPU computing type: adapting to the computing characteristics of different CPU architectures; interrupt handling module: interfacing with the hardware's interrupt controller; and peripheral interface: adapting to the interface logic of various peripherals (such as serial ports, DMA, etc.).

[0040] The register abstraction layer is used to define the functions, configurations, and access permissions of registers. The functions of the register abstraction layer include: configuration management: managing the parameter configuration logic of registers; function management: defining the hardware function implementation corresponding to registers; access permissions: setting the read and write permissions of registers (such as read-only, writable at a specific privilege level, etc.); address mapping: recording the mapping relationships such as the physical address and address range of registers.

[0041] The resource management layer is responsible for resource allocation and coordination. Its functions include: dynamic configuration: dynamically adjusting resource allocation strategies based on system operating status; resource coordination: coordinating resource usage conflicts between different VMs / domains to achieve reasonable resource allocation; and static configuration: completing basic resource allocation and initialization settings during system initialization.

[0042] The scheduling and interrupt management layer is responsible for the system's task scheduling and interrupt handling. Its functions include: scheduling mechanism: formulating scheduling rules such as VM / task running priority and time slice allocation to achieve efficient allocation of system resources; interrupt management: handling the distribution, response, and priority arbitration of hardware interrupts to ensure the system's real-time response to external events.

[0043] The monitor core layer is the core functional layer of the virtual machine monitor, and its functions specifically include: Virtualization Management: Responsible for the virtualization logic scheduling and operation control of virtual machines; Memory Isolation: Implements memory space isolation between different VMs / domains to prevent unauthorized access; Creation / Destruction / Restart: Provides full lifecycle management operations for VMs; Security Management: Performs security-related controls such as VM / domain operation security and data security; VM Interaction: Supports communication, resource sharing, and other interaction mechanisms between different VMs.

[0044] based on Figure 2 The virtual machine monitor structure shown in this application provides a development architecture for a partition management program, referring to... Figure 3 The diagram shows a schematic of the structure of a partition management program development apparatus according to an embodiment of this application. The partition management program development apparatus specifically includes an input layer, a strategy layer, a modeling layer, and a generation layer.

[0045] The input layer corresponds to step 101 and is used to receive the chip's register description data, chip behavior specification data, and chip architecture configuration data.

[0046] The policy layer corresponds to step 101 and is used to receive partition policy data. Partition policy data represents the virtualization layout of functional partitions. Users can describe virtualization layout-related policy content such as VM-CPU binding, memory segmentation, device passthrough, and interrupt routing based on the HVC (Hypervisor Call) dialect, which is an extension of MLIR (Multi-Level Intermediate Representation). Additionally, users can supplement higher-level policies such as the number of security domains, runtime leases, and audit switches using YAML (YAML Ain't Markup Language) files.

[0047] The modeling layer corresponds to steps 102 to 105 and is used to generate an intermediate representation structure based on the relationship between resources, permissions, and timing.

[0048] The modeling layer in this application embodiment is used to define the "roles" of registers without relying on a single chip. Function Permissions Semantic modeling is performed on the "time sequence".

[0049] Among them, the roles represent the responsibilities of registers in the operating system. Registers are specifically divided into the following categories: control / configuration class, responsible for controlling interrupts, enabling / disabling DMA, setting peripheral modes, etc.; status class, which can reflect the operating status of hardware or software by reading register data; data class, used to store various types of data such as ordinary data and symbolic data; and index / table entry class, which is used to store index information of various table entries.

[0050] A function refers to the impact and effect on the operating system after performing read and write operations on a register. Functions generally need to be bound to corresponding hardware resources, such as address ranges and device instances. A typical scenario is configuring a serial port to read-only monitoring mode.

[0051] Permissions refer to the access level and privilege level of registers, clearly defining the range of registers that can be accessed at the system layer and the application layer.

[0052] Timing refers to the access order specification of registers, defining the read and write operation process, effective conditions, and effective timing of registers.

[0053] Taking the MMU component of the A53 (Advanced RISC Machine 53) architecture as an example: the VTTBR_EL2 register (Virtualization Table Base Register for EL2) has the role of control; its function is to specify the base address and context of the page table in the S2 (Stage-2) stage; its permissions are EL2 (Exception Level 2) read and write only; the timing requirement is that after the write operation is completed, the ISB (Instruction Synchronization Barrier) / DSB (Data Synchronization Barrier) barrier instructions and the TLB (Translation Lookaside Buffer) failure sequence must be executed. The generation layer corresponds to step 106, which is used to generate the target file for machine loading based on the intermediate data structure. This target file may contain the initialization C language source code and header files for various partition management programs such as Bao, Jailhouse, Dom0-less Xen, and Hyperlaunch. Furthermore, the generation layer can link the target file into a target binary file or image file to support the bootloader's flashing operation.

[0054] In step 101, the chip is a miniaturized electronic system manufactured using semiconductor technology, integrating electronic components such as transistors, resistors, capacitors, and inductors, as well as their interconnections, onto a small semiconductor wafer (such as a silicon wafer). As the core component of an electronic device, the chip performs specific signal processing, logic operations, data storage, or control functions through its highly integrated internal circuitry.

[0055] In chip design, architecture refers to the overall functional specifications and structural planning. Architecture can include two levels: instruction set architecture and microarchitecture. The instruction set architecture defines the basic set of executable instructions, register organization, addressing modes, etc., and is the contract between software and hardware. The microarchitecture specifically implements the instruction set execution flow, including pipeline design, cache structure, and the connection and cooperation methods of functional units. Architecture determines the chip's performance potential, functional characteristics, power consumption level, and compatibility with system software. In practical applications, input data can be user-inputted data or pre-stored data. For example, development tools can provide an input interface, allowing users to input data. The input data includes: chip register description data, chip behavior specification data, chip architecture configuration data, and partitioning strategy data.

[0056] For example, users can import specialized files to input register description data. This register description data can be a SystemRDL (System Register Description Language) or IP-XACT (Intellectual Property Extensible Configuration Transaction) file. The SystemRDL or IP-XACT file is used to describe the register's bit fields, reset values, side effects, and other attribute information.

[0057] For example, users can import the chip's behavior specification data. This data can be a behavior specification DSL (Domain-Specific Language). The behavior specification DSL records timing information such as register initialization procedures, polling mechanisms, and the dependency order of different register operations. For instance, when performing a certain function, the control register must first be initialized, then the status register must be polled at a specific frequency, and there are strict sequential dependencies between the various register operations. The behavior specification DSL specifically includes primitives such as sequence, poll, wait, depend_on, and param, which combine to form the device initialization protocol.

[0058] In summary, System RDL and IPXACT contain structured hardware specifications, typically register description packages provided by the chip manufacturer. The chip's behavioral specification data clarifies the specific usage methods, configuration parameters, and operational sequence of registers, thereby ensuring that register configurations take effect. These two types of data complement each other, jointly describing the hardware specifications, including the structural definitions and behavioral logic of registers within the chip.

[0059] This application embodiment can provide a hardware template for the architecture to input chip architecture configuration data. The hardware template contains chip architecture setting information. The setting information may include at least one of the following: architecture type, privilege model, memory management unit, storage management unit type, and interrupt controller type.

[0060] Specifically, the architecture types include: ARM (Advanced RISC Machine) architecture, PowerPC (Performance Optimization With Enhanced RISC – Performance Computing) architecture, etc. The architecture type defines the chip's instruction set architecture and core computing logic, and is the foundation for determining the chip's performance characteristics and software compatibility.

[0061] The privilege model clarifies the rules for classifying privilege levels during chip operation, as well as the resource access permissions and operational restrictions under different privilege levels. For example, programs with lower privilege levels cannot directly access registers or memory regions with higher privilege levels, thereby ensuring the security and stability of system operation.

[0062] Memory management unit types specifically include MMU (Memory Management Unit) or MPU (Memory Protection Unit). The MMU is responsible for mapping virtual addresses to physical addresses and supports memory paging management and access control; the MPU focuses on protecting physical memory regions, dividing different regions into read, write, and execution permissions, and is suitable for embedded scenarios with high real-time requirements.

[0063] The storage management unit type can be selected to include units such as SMMU (System Memory Management Unit) and PPU (Peripheral Protection Unit). The SMMU performs address translation and access control for peripheral DMA operations, preventing unauthorized memory access; the PPU protects the access paths of on-chip peripherals, improving the security of peripheral data interaction.

[0064] Interrupt controller types specifically include: GIC (Generic Interrupt Controller), NVIC (Nested Vectored Interrupt Controller), and AIA (Advanced Interrupt Architecture), etc. These interrupt controllers are responsible for the distribution, priority arbitration, and response processing of interrupt signals, and are the core components for enabling the system to respond to external events in real time.

[0065] The user's description of the functional partitioning goals in the development tools is one of the steps in inputting partitioning strategy data. In the specific implementation, the user can input the type of domain or virtual machine to be run, such as a control domain or diagnostic domain; at the same time, define the real-time level and security level corresponding to each domain or virtual machine, as well as the allocation scheme and sharing rules of the required peripherals, such as specific constraints like "shared serial port read-only, doorbell notification".

[0066] Based on this, users can further refine the input of partitioning policy data through the visual configuration interface, specifically including selecting and configuring the following resource mapping and management policies: memory region partitioning range and access permissions, device usage mode (passthrough mode or virtualization mode), IRQ (Interrupt Request) routing rules and priority sorting, shared memory allocation scheme and doorbell notification mechanism, and DMA whitelist settings and bandwidth limits, etc.

[0067] In step 102, a structured register semantic structure is constructed by parsing the chip's register description data and behavioral specification data. Specifically, the register semantic structure includes: nodes corresponding to registers or bit fields, relationships between different nodes, constraint information corresponding to the nodes, and index information of the nodes in the address space tree and hardware resource categories. This register semantic structure organizes register and bit field information in node form and records the relationships between nodes, access constraints, and address space tree / hardware resource category indexes. This register semantic structure provides a unified data foundation for subsequent intermediate data structures, supports the partition management program in accurately understanding and controlling chip hardware resources, and thus achieves a secure and reliable isolated operating environment.

[0068] In a specific implementation, the process of generating the register semantic structure of the chip based on the chip's register description data and the chip's behavioral specification data specifically includes: Step A1: Perform structural parsing on the register description data of the chip to obtain register structure information; Step A2: Perform behavior parsing on the behavior specification data of the chip to obtain register behavior information; Step A3: Generate the register semantic structure of the chip based on the register structure information and the register behavior information.

[0069] In step A1, the register structure information may include: register bit fields, reset values, read / write attributes, address mapping information, peripheral directories, and address range indices, etc. Register-level attributes include: address (base address + offset / step), size, reset value, and access attributes. Bit field-level attributes include: bit range, reset value, access attributes, and side effects.

[0070] The register description data of a chip can cover the register definitions of various peripherals such as camera peripherals, memory management units, timers, and interrupt controllers. When the above register description data contains a single register, the register's attribute information, such as address mapping information, bit field definitions, reset values, and read / write attributes, can be directly extracted from that single register. In the case of register groups in the above register description data, the register group can first be expanded into multiple registers, for example, expanding the register group GICD_ISENABLER[n] into n (n is a positive integer) registers, and then performing attribute extraction operations on each of the expanded registers.

[0071] In step A2, the register behavior information specifically includes: the behavior logic of register operations, the behavior sequence, and dynamic behavior information such as timing constraints, triggering conditions, and state transitions.

[0072] In practical implementation, functional domain processes such as peripheral initialization and feature activation can be mapped to register behaviors. For example, the interrupt enabling process can be mapped as follows: GICD_CTLR (GenericInterrupt Controller Distributor Control Register) configuration → ISENABLER* (Interrupt Set-Enable Registers) register setting → barrier (DSB, ISB) (Instruction Synchronization Barrier / Data Synchronization Barrier Instruction) execution sequence, and a write-after-visibility tag is added to the relevant register behaviors. This tag is used to clarify the effective timing and visibility range of register write operations, so that subsequent operations that depend on the register configuration (such as interrupt response, permission switching) can accurately perceive the latest state of the register, avoiding configuration failure problems caused by hardware pipeline, cache coherence, or instruction reordering.

[0073] In step A3, register structure information and register behavior information are mapped to the entity nodes corresponding to the registers or bit fields. Static register structure information is used as a carrier to anchor dynamic behavior information, and the hardware structure attributes and operation behavior logic of the registers are associated. Finally, a register semantic structure containing node relationships, behavioral constraints and semantic tags is constructed.

[0074] This register semantic structure achieves unified modeling of register static structure and dynamic behavior, and establishes a mapping link between register hardware attributes and operational behavior. It provides a complete and consistent data foundation for subsequent automatic generation of intermediate data structures, development of access interfaces, timing verification, and coverage analysis. It also provides a unified and accurate hardware semantic benchmark for the generation of partition management programs. This ensures that upper-layer software access to registers conforms to the underlying hardware specifications and meets the timing requirements of function execution, ultimately improving the consistency of software and hardware collaborative development, and enhancing development verification efficiency and code quality.

[0075] In a specific implementation, step A3, which generates the register semantic structure of the chip based on the register structure information and the register behavior information, specifically includes: Step A31: For the registers in the register structure information or the bit fields in the registers, construct nodes and aggregate the nodes according to hardware resources; Step A32: Construct edges based on the relationships between different nodes; Step A33: Based on the register attribute information in the register structure information and the timing information in the register behavior information, add corresponding constraint information for the node and the edge; Step A34: Establish the index of the node in the address range tree, and establish the index of the node to the hardware resource category.

[0076] In step A31, corresponding nodes are constructed for the registers or bit fields in the register structure information, and these nodes are aggregated and classified according to the functional domains corresponding to the hardware resources. Specifically, the nodes are divided into functional domains such as MMU (Memory Management Unit), IRQ (Interrupt Controller), IOMMU (Input / Output Memory Management Unit), TIMER / CLK (Timer / Clock), and peripherals (such as cameras, timers, etc.), realizing the structured organization of nodes according to hardware logic. This step organizes the physical register resources according to functional modules, providing a structural foundation for subsequent modeling.

[0077] Step A32 constructs the edges of the semantic graph based on the relationships between different nodes. The edge types specifically include the following three types of relationships: first, containment relationship, that is, the affiliation relationship from bit field to register; second, dependency / timing relationship, which is injected by register behavior information; and third, alias / overlap relationship, which is used to characterize the association logic of alias mapping and address overlap of registers or address ranges.

[0078] Taking the timing dependency edge corresponding to the action sequence "write to register A → execute DSB / ISB barrier instruction → read register B" as an example, a directed edge from register A node to register B node can be established. The core constraint property of this edge is: after completing the write operation on register A, the DSB / ISB barrier instruction must be executed first to realize the hardware effectiveness of the write operation, and only then can the read operation be performed on register B.

[0079] Step A33 adds constraint information to the constructed nodes and edges. This constraint information may include: attribute information of registers or bit fields contained in the register structure information, and timing rules contained in the register behavior information.

[0080] Examples of register or bit field attribute information include: XN (Execute Never) and RO (Read Only).

[0081] Examples of timing rules included in register behavior information include: GICv3 (Generic Interrupt Controller version 3) interrupt routing and priority model constraints, SMMU (System Memory Management Unit) flow table / CB (Control Block) rule constraints, TLBI (Translation Lookaside Buffer Invalidate), and node set constraints for cache invalidation and barrier operations.

[0082] Step A34 establishes an index of the node in the address range tree for quick querying of address conflicts and overlay relationships; at the same time, it establishes an index of the node to the hardware resource category (functional domain) to facilitate quick retrieval by functional module.

[0083] The register semantic structure in this application embodiment can be in JSON (JavaScript Object Notation) format or memory model format. Nodes, edges, constraint information, and indexes can be fields in JSON format.

[0084] It should be noted that, in this application embodiment, nodes in the register semantic structure can be classified according to functional domain category or hardware resource category (MMU / MPU / interrupt / peripheral / clock). These nodes contain attribute information such as access attributes, reset values, and side-effect metadata.

[0085] vReg Layer (Virtual Register Layer): Exposes a "restricted / redirected" register view to the virtual machine, supporting pass-through / sharing and strong isolation; In step 103, the virtual register structure represents the virtual registers allocated to the virtual machine, along with the corresponding permissions and timing. A mapping mechanism allocates physical register resources to the virtual machine according to a partitioning strategy, constructing a virtual register view containing permission and timing constraints. This virtual register structure enables the virtualization and isolation of hardware resources, providing each virtual machine with an independent register access view and supporting concurrent operation of multiple virtual machines. Through the virtual register structure, virtual machines can transparently access physical registers without being aware of the underlying hardware details; the injection of permission and timing constraints ensures that the operation of a virtual machine does not interfere with other virtual machines or compromise system security, providing a basic data model for subsequent virtual machine scheduling and resource management.

[0086] Step 103, based on the register semantic structure, determines the virtual register structure corresponding to the virtual machine in the partitioning strategy data, specifically including: Step B1: Allocate target hardware resources to the virtual machine according to the partitioning policy data; the hardware resource category to which the target hardware resources belong corresponds to a target register; Step B2: Determine the permissions corresponding to the target register; Step B3: Map the target register to a virtual register; Step B4: Generate the virtual register structure corresponding to the virtual register; the virtual register structure is used to represent the virtual register allocated to the virtual machine, the permissions and timing corresponding to the virtual register.

[0087] Step B1 allocates target hardware resources to the virtual machines according to the partitioning strategy data. Specifically, according to the preset partitioning strategy, each virtual machine is allocated exclusive access to physical hardware resources, including specific peripherals (such as network controllers and storage controllers) and MMIO address ranges, so that the resources of each virtual machine are fixed and do not overlap, thereby achieving strong isolation and avoiding performance uncertainty and complexity caused by runtime resource contention. The hardware resource categories to which these allocated target hardware resources belong all correspond to matching target registers, providing hardware-level foundational support for the subsequent construction of virtual registers.

[0088] Step B2 determines the permissions corresponding to the target register. This can be done by following the principle of least privilege, security-tuning the access permissions of each target register or its bit fields, and using read / write masks to achieve fine-grained control over these access permissions. For registers in pass-through mode, read / write permissions are enabled by default, but high-risk bit fields such as reset, global switches, and reserved bits are masked. Alternatively, the permissions of the registers corresponding to the shared resource window can be adjusted to read-only (RO) + execute-only (XN). Alternatively, system registers requiring global control by the virtual machine monitor can be completely removed from the guest virtual machine's access view to improve the security and isolation of hardware resource access.

[0089] Step B3 maps the target registers to virtual registers. This mapping process specifically includes: generating virtual register aliases or renumbering the set of target registers exposed by the virtual machine, constructing an independent virtual address space completely decoupled from the physical register layout. For complex multi-bit control fields in registers, they can be simplified to preset security enumeration values ​​or single-bit control bits according to security policies, thereby limiting the virtual machine's configuration options, simplifying the virtual machine's operating logic, and enhancing security. Furthermore, for doorbell registers that need to interact with the virtual machine monitor, they are exposed to the virtual machine as virtual registers; when the virtual machine writes to this virtual register, a trap is triggered, which is intercepted and processed by the virtual machine monitor, ultimately transforming it into an event injected into the virtual machine, thereby achieving secure and controlled indirect interaction between the virtual machine and the underlying hardware.

[0090] The virtual register structure in step B4 specifically includes the following fields: Virtual machine identifier field, used to uniquely identify the virtual machine; Register or bit field identifier field, corresponding to the node in the register semantic structure; Alias ​​address field, which is the alias address of the virtual register; Read / write mask field, representing the minimum privilege granted; Trap or emulation policy field, where trap refers to the trap mechanism being triggered when the virtual machine executes a specific instruction or accesses a restricted virtual register, and emulation refers to the virtual machine monitor emulating the execution of virtual machine instructions; and Trimming attribute field, which is the trimming attribute of the register after operations such as setting access permissions.

[0091] The generation process of this virtual register structure includes the following steps: First, a cross-virtual machine consistency check is performed. This consistency check is used to identify resource conflicts between virtual machines, verify the unique route of interrupt requests, and verify the coverage of the direct memory access whitelist. Next, based on the results of the consistency check, a trap table is generated. If the system is equipped with a system memory management unit (MMU), then a flow table and control block are generated; if there is no MMU, then a bus access whitelist needs to be generated. Then, the virtual registers allocated to the virtual machines, their corresponding access permissions, and timing rules are integrated to generate the virtual register structure. Its output includes a virtual register view for each virtual machine, a trap table, and the flow table or access whitelist of the MMU. The virtual register view specifically includes: a virtual machine identifier field; a register or bit field identifier field; an alias address field; a trap or emulation policy field; and a pruning attribute field.

[0092] In step 104, a target strategy that matches the architecture configuration data of the chip is determined based on the partitioning strategy data.

[0093] The partitioning policy data includes user-defined partitioning requirements (such as virtual machine resource allocation and permission settings), while the chip's architecture configuration capabilities characterize the chip's actual hardware capabilities (such as register layout, MMU support, and interrupt controller type).

[0094] The process of determining the target strategy involves consistently matching the resource requirements, access permissions, and security rules defined in the partitioning strategy data with the physical resource layout, hardware characteristics, and inherent limitations described in the chip architecture configuration data. This process enables partitioning planning to be implemented feasiblely and efficiently within the actual hardware capabilities of the chip. For example, the virtual functional domains specified in the strategy are mapped to the physical isolation mechanisms supported by the chip (such as memory controllers and IOMMU flow tables), and the resource allocation scheme is verified and optimized based on hardware constraints such as address ranges and interrupt routing, ultimately generating a target strategy tightly coupled with the underlying hardware.

[0095] In a specific implementation, the process of determining a target strategy that matches the chip's architecture configuration data based on the partitioning strategy data specifically includes: Step C1: Match the first architecture corresponding to the strategy in the partitioning strategy data with the second architecture in the chip's architecture configuration data to obtain a successfully matched candidate strategy; Step C2: Sort the candidate strategies according to the ranking indicators to obtain the ranking results; the ranking indicators include: resource usage indicators and / or functional integrity indicators. Step C3: Select the target strategy from the sorting results.

[0096] In step C1, the first architecture (the hardware platform specification that the policy expects to run, such as a specific CPU instruction set, MMU type, or IOMMU (Input / Output Memory Management Unit) specification) of each policy in the partitioning policy data can be compared with the actual second architecture of the chip (the actual architecture configuration provided in the chip hardware description file, such as a specific ARM series core, GIC (Generic Interrupt Controller) version, or SMMU (System Memory Management Unit) configuration).

[0097] For example, a strategy might require the architecture to support ARM's GIC version 3 and SMMU version 2; if the target chip's architecture configuration data indicates that it supports GIC version 3 and SMMU version 2, then the strategy is a successful match and becomes a candidate strategy.

[0098] For step C2, after obtaining a set of candidate strategies, these strategies can be optimized and ranked according to the set ranking metrics to identify the optimal solution. Commonly used ranking metrics include resource usage metrics and functional integrity metrics. Resource usage metrics are used to evaluate the utilization of hardware resources (such as CPU cores, memory regions, and DMA channels) by the strategy. Resource usage metrics aim to minimize or balance resource usage while meeting functional requirements, avoiding idle resources in some partitions while resource strain is present in others. Functional integrity metrics are used to evaluate the extent to which the strategy meets the overall functional requirements of the system. This may include whether the allocation of critical peripherals (such as display controllers and network controllers) is complete, and whether necessary security features (such as the isolation strength between different partitions) are supported.

[0099] In practical applications, a quantitative score of the ranking metric can be calculated for each candidate strategy, and the ranking score can be determined according to the priority of the ranking metric (e.g., prioritizing resource utilization efficiency over functional integrity). The ranking results are then formed based on the ranking scores from largest to smallest.

[0100] For step A3, based on the aforementioned ranking results and considering the actual needs and priorities of target application scenarios such as intelligent vehicles, the strategy with the best overall performance is selected as the target strategy from the ranked candidate strategies. This target strategy must simultaneously meet the core requirements of hardware architecture compatibility, resource utilization efficiency, and functional integrity. It must be able to adapt to the actual architecture configuration of the chip and achieve the best balance between hardware resource consumption and partitioning function implementation, providing a directly executable strategy basis for subsequent steps.

[0101] In this application embodiment, the binding relationship between the target policy and the nodes in the register semantic structure can be pre-constructed. The binding relationship is used to bind the rules such as resource allocation, permission settings and timing constraints defined in the target policy to specific register nodes.

[0102] The process of constructing the binding relationship between the target policy and the nodes in the register semantic structure specifically includes: Step D1: Configure the attribute information of the memory management node in the register semantic structure according to the virtual machine memory segment information in the target policy; or Step D2: Configure the attribute information of the device management node in the register semantic structure according to the device pass-through sharing mode information in the target strategy; or Step D3: Configure the attribute information of the interrupt control node in the register semantic structure according to the interrupt target and interrupt priority information in the target strategy; or Step D4: Configure the attribute information of the DMA control node in the register semantic structure according to the direct memory access (DMA) whitelist information in the target policy.

[0103] Steps D1 to D4 can be used to bind the abstract policy description to specific hardware resource configurations. This binding process, based on register or bit-field nodes in the register semantic structure, transforms the configuration intent regarding memory, devices, interrupts, and DMA in the target policy into attribute configurations for the corresponding registers or bit-field nodes used for hardware management. Essentially, this is the process of instantiating architectural specifications (such as rules for MMU / MPU, GIC / ITS, SMMU / IOMMU) into the registers or bit-fields of specific hardware resources (address ranges, registers / bit fields, IRQ numbers, device IDs, etc.), thereby providing a deterministic data foundation for subsequent code generation.

[0104] In step D1, based on the virtual machine memory segments (such as address ranges and permissions) defined by the target policy, the registers or bit-field nodes related to the functions of the Memory Management Unit (MMU or MPU) in the register semantic structure are configured. Specifically, the access permissions (such as readable, writable, and executable) and attributes (such as caching policies) of the memory segments in the target policy are injected into the registers or bit-field nodes corresponding to the MMU page table descriptors or the registers or bit-field nodes corresponding to the MPU region configurations. The specific instruction paths required for the subsequent generation of the Stage-2 page table or MPU region table, as well as the necessary Translation Lookaside Buffer Invalidation (TLBI) and memory barrier operation points, are marked.

[0105] In step D2, based on whether the device uses pass-through or shared mode as determined by the target policy, registers or bit-field nodes related to device management functions in the register semantic structure are configured, such as registers or bit-field nodes associated with SMMU / IOMMU flow table functions, or registers or bit-field nodes of a specific device controller. For pass-through devices, the corresponding registers or bit-field nodes are configured to be exclusively accessed by the specified virtual machine; for shared devices, secure sharing among multiple virtual machines can be achieved by configuring access permissions for the corresponding registers or bit-field nodes or interrupt routing-related bit-fields.

[0106] Step D3 takes the interrupt target information defined in the target policy—that is, the virtual CPU to which the interrupt should be sent and the corresponding interrupt priority information—and applies it to the register semantics structure and the registers or bit fields related to the interrupt controller function. Specifically, it configures the relevant registers or bit fields in the interrupt dispatcher or interrupt translation service. By adjusting the parameters of the corresponding bit fields, it routes the specific interrupt number to the virtual CPU specified by the policy, and simultaneously sets the required priority and affinity for this interrupt. This ensures that the interrupt is delivered accurately and promptly according to the policy.

[0107] Step D4 configures the registers or bit-field nodes related to DMA control functions in the register semantic structure (such as registers or bit-field nodes associated with SMMU context functions, or registers or bit-field nodes corresponding to flow table entries) based on the system memory management unit flow table or bus whitelist information defined by the target policy. By setting the mapping relationship between flow table entries and physical addresses and access permission bits in the corresponding registers or bit-field nodes, only devices within the whitelist can initiate DMA operations and can only access their authorized memory regions, thereby effectively preventing DMA attacks or out-of-bounds access.

[0108] In step 105, the register semantic structure, virtual register structure, and policy-node binding relationship are integrated and structured, transforming the scattered hardware semantic definitions, virtual register abstract models, and policy control rules into a unified intermediate data structure that can be parsed by subsequent processes. This intermediate data structure bridges the gap between "policy-semantics-virtual hardware" and "code / development generation results." The resource permission timing structure clarifies the allocation scope, access permissions, and timing constraints of virtual machine hardware resources; the virtual register structure solidifies the abstract form of virtual hardware; the interrupt routing structure specifies the interrupt distribution path and priority rules; the whitelist structure defines the hardware access boundaries of the virtual machine; and the lease directory structure defines the resource usage cycle, priority, and preemption mechanism. This provides standardized and deterministic data for subsequent partition management program code generation and hardware configuration solidification, ensuring that the target policy is accurately and consistently implemented in the underlying hardware.

[0109] The intermediate representation structure includes: a resource permission timing structure, a virtual register structure, an interrupt routing structure, a whitelist structure, and a lease directory structure; the resource permission timing structure is used to represent the hardware resources allocated to the virtual machine, the permissions and timing corresponding to the hardware resources; the whitelist structure represents the hardware resources that the virtual machine can access; the lease directory structure represents the virtual machine's lifecycle, priority, and preemption rules for using resources.

[0110] The resource permission timing structure can be in JSON format, specifically including: virtual machine field, virtual machine bound CPU field, storage field, device field, timing field, and reference field. The storage field stores information such as the virtual machine, memory segment identifier, memory type, and attributes; the device field stores data related to the virtual machine, device identifier, and memory-mapped input / output address range; the timing field records timing constraints for hardware resource allocation and access; and the reference field contains addresses with structures such as whitelists.

[0111] The virtual machine field stores the identifiers and other relevant information of all virtual machines, clearly identifying each virtual machine involved.

[0112] The CPU field bound to the virtual machine records the set of CPUs bound to each virtual machine, clarifying the allocation of hardware CPU resources for the virtual machine.

[0113] The memory mapping field is an array containing virtual machine identifier, memory segment identifier, memory type, and memory attributes, which describes the memory allocation of the virtual machine.

[0114] The device mapping field stores the virtual machine identifier, device identifier, and memory-mapped input / output address range, which describes the device resources that the virtual machine can access and their address mappings.

[0115] The timing field is used to record timing constraints for hardware resource allocation and access, ensuring that hardware resources are accessed in a specific order and according to time requirements.

[0116] The reference field contains some references, such as pointing to intermediate data structures like whitelist structures, which can be associated with other relevant hardware control rules.

[0117] The generation process of fields in the resource permission sequence structure specifically includes: Virtual Machine Field: The information of the virtual machine contained in the target policy is added to the virtual machine field to clarify the virtual machine object targeted by the entire resource permission management. This virtual machine field provides the virtual machine subject identifier for the allocation and control of all subsequent hardware resources.

[0118] CPU Binding Field: Based on the rules for allocating virtual machine CPUs in the target policy, extract the configured attribute information of CPU management-related nodes in the register semantic structure. These attribute information are core rules preset in combination with the underlying hardware characteristics, such as the exclusive identifier of the CPU core and the compatibility control bits of multi-VM time-sharing scheduling. Based on these configured constraint attributes, verify and determine the final set of CPUs that each virtual machine can be bound to, and then fill the determined set of CPUs into the CPU Binding Field.

[0119] Memory Mapping Field: Based on the virtual machine memory segment information defined by the target policy, extract the configured attribute information of the memory management node in the register semantic structure. This attribute information is the configuration completed previously based on the virtual machine memory segment information in the target policy, specifically including memory access permission bits (readable, writable, executable, etc.), caching policy parameters, address range constraints, and other core contents. Then, according to the specified array format, fill the virtual machine, memory segment identifier, memory type, and the attribute information extracted from the memory management node into the memory mapping field. At the same time, based on the instruction interaction logic of the memory management node in the register semantic structure, determine the specific instruction path required for the subsequent generation of the Stage-2 page table or MPU area table, as well as the necessary TLB invalidation and memory barrier operation points, and supplement them into the extended attribute items of this field.

[0120] Device Mapping Field: Based on the device pass-through or shared mode determined by the target policy, extract the attribute information already configured by the device management node in the register semantic structure. This attribute information is the configuration completed previously based on the device pass-through / shared mode information in the target policy. If it is a pass-through device, it contains the control bit configuration rules for exclusive device access. If it is a shared device, it contains the control logic of access permission bits and interrupt routing bit fields. Then, fill the virtual machine, device identifier, MMIO address range and the above configuration rules extracted from the device management node into the Device field to clarify the virtual machine's access mode to the device and the basis for hardware-level control.

[0121] Timing Field: Extract the configured attribute information of interrupt control nodes and DMA control nodes from the register semantic structure. This attribute information is configured based on the interrupt target and priority information and DMA whitelist information in the target policy. Specifically, it includes timing control bit fields such as interrupt response window period, DMA transfer timing constraint bits, and operation barrier trigger conditions. Combined with the definition of resource access order and dependency relationship in the target policy, the timing configuration of these nodes is transformed into parsable resource access timing rules and then filled into the timing field.

[0122] Reference field: Based on the requirements of the resource permission timing structure and the association with other hardware management rules, the address information of external structures such as DMA whitelists is filled into this reference field. The core management rules of the external structures come from the attribute information of the DMA management node in the register semantic structure. This field indirectly associates the configuration node of the register semantic structure through address reference, so that the complete hardware management policy can be called in subsequent processing.

[0123] The interruption routing structure can be in JSON format. The interruption routing structure specifically includes the following fields: interruption source identifier, destination, priority affinity, and pattern.

[0124] The interrupt source identifier field is used to specify the specific source of the interrupt. The configured interrupt source identifier bit field and number mapping table information can be extracted from the interrupt control node. Based on this extracted information, the field content of the interrupt source identifier field is determined to ensure consistency between the interrupt source identifier and the hardware register configuration.

[0125] The target field can correspond to an array, which records the identifier of the virtual machine to which the interrupt is to be sent and the virtual CPU cores within that virtual machine.

[0126] The generation of the target field is a process of converting hardware interrupt target information into a recognizable identifier in the virtualization environment. This process includes extracting physical target information from the interrupt control register configuration and then converting the physical target information into a virtualization target identifier according to the virtual machine mapping rules.

[0127] First, the configured interrupt target information is extracted from the interrupt control node (e.g., the interrupt target register of the GIC) within the register semantic structure. This interrupt target information indicates which physical CPU core(s) the interrupt should be sent to on the physical hardware. Then, based on the virtual machine-to-physical CPU mapping established in the predefined partitioning strategy, the physical CPU core identifier is converted into the corresponding virtual machine identifier and the virtual CPU identifier within that virtual machine. For example, physical cores 0 and 1 might map to virtual CPU 0 of virtual machine A, while physical cores 2 and 3 might map to virtual CPU 0 of virtual machine B. Finally, the converted virtual machine identifier and the virtual CPU core within that virtual machine are filled into the target field, thus explicitly specifying the final destination of the interrupt in the virtualization environment.

[0128] The priority affinity field includes a priority field and an affinity field, representing the priority and affinity of the corresponding interrupt. The mode field is used to indicate the routing mode of the interrupt.

[0129] In interrupt routing configuration, affinity represents the degree of association or preference between an interrupt and a specific processing unit (such as a physical CPU core). Simply put, it determines which physical CPU core(s) an interrupt is more "preferred" to handle. Higher affinity means the interrupt will be preferentially sent to the designated physical CPU core, which helps improve the efficiency and predictability of interrupt handling. For example, if an interrupt occurs frequently and has high real-time requirements, configuring it to have high affinity with a specific, low-load, and suitable CPU core can reduce the overhead of migrating the interrupt between different cores, allowing the interrupt to be processed faster. Conversely, if affinity is low, the interrupt may be assigned to multiple different CPU cores for processing.

[0130] In the interrupt routing structure, the generation of the priority, affinity, and mode fields essentially involves converting the interrupt control parameters configured in the hardware registers into standardized information that the virtualization layer can understand and use. The specific generation process is as follows: The content of the priority field originates from the interrupt priority bit field configured in the interrupt management node. This bit field configuration is the result of previous configuration operations on the interrupt controller's priority configuration register based on the target strategy. When generating the interrupt routing structure, the specific priority value is extracted from the corresponding register bit field and filled into the priority field.

[0131] The process for determining the affinity field content is as follows: First, the configured affinity value is extracted from the interrupt control node. This affinity value corresponds to the target processing unit identifier configured in the interrupt controller register. Then, the extracted affinity value is checked and matched with the attributes of the physical CPU core (such as core exclusivity, time-sharing scheduling characteristics, etc.). If the two are consistent, it means that the interrupt routing configuration conforms to the system resource allocation strategy, and the rule corresponding to the affinity value is directly determined as the affinity field content. If the two are inconsistent, the affinity field content is regenerated after adjustment according to the system's preset backup rules.

[0132] The mode field defines the interrupt triggering and routing method. Its content can be derived from the bit fields already configured on the interrupt control node. The mode field includes the interrupt triggering mode (e.g., level-triggered or edge-triggered, configured in GICD_ICFGR). <n>(e.g., registers) and interrupt dispatch mode (configured in GICD_IROUTER) <n>(e.g., IRM bit fields). The configuration of these register bit fields is also the result of previous operations based on the target strategy. The generation process will convert the original configuration values ​​in the registers (e.g., binary '1' representing edge triggering) into the corresponding readable enumerated values ​​(e.g., "edge") in the mode field.

[0133] The whitelist structure can be in JSON format. The composition of the whitelist structure's fields varies depending on the presence of an SMMU (System Memory Management Unit). When an SMMU is present, the whitelist structure's fields are an array of streams, containing information such as device identifier, stream identifier, context library, page table reference, and allowed buffers. When the system does not have an SMMU, the whitelist structure's fields are an array of bus_allowlist, containing information such as master device identifier / device identifier, address range, and data transfer direction.

[0134] In practical applications, the field content of the whitelist structure can be determined based on hardware topology and access control policies. For scenarios with a Smart Stream Management Unit (SMMU), hardware configuration data such as configured device flow binding information, context library configuration parameters, page table references, and allowed buffer ranges are first extracted from the SMMU management node. This extracted information is then directly mapped to the content of fields such as device identifier and flow identifier in the `streams` array. For scenarios without a SMMU, information such as device bus access permission configuration, address mapping rules, and data flow constraints are first extracted from the bus management node. This extracted information is then used as the basis to determine the content of fields such as master device identifier / device identifier, address range, and data transfer direction in the `bus_allowlist` array, thereby achieving matching between the field content and the hardware-level DMA access control rules.

[0135] The lease directory structure can be in JSON format, which may include: a lease array containing fields such as lease identifier, identifier extension, lease validity period, access protection constraint, and synchronization barrier instruction configuration. These multiple fields together define the lease's lifecycle, access permissions, and synchronization rules.

[0136] In practical applications, the field content of the lease catalog plan is determined based on the register semantic structure. If the lease validity period field is involved, the configured lease validity period parameter is extracted from the register semantic structure of the memory management node; for the access protection constraint field, the resource access protection rules in the register semantic structure are obtained from the device management node; if it is a synchronization barrier instruction configuration field, the barrier instruction hardware configuration data in the register semantic structure is extracted from the DMA management node; lease identification related fields can be extracted from the register semantic structure of the device management node to obtain lease identity information.

[0137] In step 106, based on the compilation process provided by MLIR (Multi-Level Intermediate Representation) technology, and relying on its principle of "layered intermediate representation and multi-level abstraction transformation," the intermediate representation structure, including resource permission timing structure, interrupt routing structure, whitelist plan structure, and lease directory structure, is progressively compiled into a machine-loadable target file. This compilation process leverages MLIR's layered transformation capabilities to achieve the implementation from high-level abstract descriptions to low-level hardware executable configurations. Simultaneously, MLIR's modularity supports flexible deployment of multiple virtualization backends, achieving isolation, security, and verifiability of the virtualization environment, thereby improving development efficiency and system reliability.

[0138] The process of compiling the intermediate representation structure into a machine-loadable object file specifically includes: Step E1: Based on the chip's architecture configuration data, convert the intermediate representation structure into hardware resource configuration data; Step E2: According to the format specifications of the partition management program, the configuration data of the hardware resources is encapsulated into a target file for machine loading.

[0139] This application embodiment can employ lowering and emitting processes to compile the intermediate representation structure into a machine-loadable object file. Lowering and emitting processes progressively transform the intermediate representation structure into a hardware-loadable and executable object file. Step E1 corresponds to the sinking process and the high-level to low-level intermediate representation conversion stage of MLIR, which is used to convert the abstract intermediate representation structure into specific hardware resource configuration data according to the chip's architecture configuration data.

[0140] Step E1 corresponds to the sinking process and the high-level to low-level intermediate representation conversion stage of MLIR. Its function is to transform the abstract intermediate representation structure into specific hardware resource configuration data based on the chip's architecture configuration data. Furthermore, this step leverages MLIR's ability to parse and convert multi-level abstract structures to perform targeted processing on different substructures.

[0141] During the processing of the resource permission timing structure, the MMU or MPU mechanism is selected based on the architecture configuration data. Next, the memory / device address ranges in the resource permission timing structure are merged and aligned for optimization, thereby generating page table entries or MPU region configuration tables. The page table entries contain key information such as physical address mappings, access permission bits, and memory type identifiers, which determine how memory is accessed and the type of data stored. The MPU region configuration table covers region base addresses, lengths, access permissions, sharing attributes, and executable attributes, used to protect and manage specific memory regions. Simultaneously, it inserts instruction hints for memory barriers and TLB invalidation operations to ensure memory access consistency in a multi-core environment.

[0142] During the interrupt routing structure processing, information such as the interrupt target vCPU, priority, and affinity is parsed. Then, based on the parsing results, an interrupt routing table and configuration register values ​​adapted to the target interrupt controller such as GIC / ITS are generated. The interrupt routing table contains the mapping relationship between interrupt numbers and target vCPUs, an interrupt priority hierarchy table, and an interrupt affinity mask, which determines which vCPU the interrupt signal should be sent to and the priority order between different interrupts. The configuration register values ​​include interrupt enable bits, dispatch mode configuration values, and interrupt trigger type identifiers, used for specific functional configuration of the interrupt controller.

[0143] During the processing of the whitelist plan structure, SMMU flow table entries or bus whitelists are generated for DMA devices based on the whitelist plan structure. Specifically, if an SMMU exists, SMMU flow table entries are generated for the DMA devices according to the whitelist plan structure; if an SMMU does not exist, a bus whitelist is generated, which can be a bus-level device access control list.

[0144] The SMMU flow table entry contains the device ID, flow ID, context library number, page table base address, and allowed buffer address range, used for fine-grained control of DMA device access permissions to memory. The bus-level device access control list contains the master device identifier, address segment start / end values, data transfer direction identifier, and access permission bits, restricting the DMA device's access range at the bus level.

[0145] During the lease directory structure processing, the lease rules for dynamic resource management are transformed into lease state machine logic and a sequence of control instructions for resource preemption and priority scheduling. The lease state machine logic encompasses lease activation / expiration conditions, state transition trigger rules, and resource occupancy timeout thresholds, used to standardize the resource leasing and usage process. The control instruction sequence includes resource preemption trigger instructions, priority determination instructions, lease permission revoke instructions, and multi-lease conflict arbitration instructions, ensuring the reasonable allocation and management of resources in resource contention scenarios.

[0146] Step E2 corresponds to the low-level intermediate representation of the MLIR process, leading to the product generation stage. According to the format specifications of the partition management program (virtualization platform), the hardware resource configuration data is encapsulated into machine-loadable object files. This stage acts as a "compiler backend." Step E2 leverages MLIR's target adaptation and code generation capabilities to complete platform-based encapsulation. The specific encapsulation process includes: First, performing backend-specific rendering. Based on the code specifications and APIs (Application Programming Interfaces) of partition management programs such as Bao, Jailhouse, and Xen, the hardware resource configuration data is transformed into a platform-adaptive form. For example, page table data such as page table entries or MPU region configuration tables are converted into Bao's C language structure arrays, and interrupt routing tables are written to Xen's device tree nodes. Subsequently, a deployable image is generated, packaging platform-specific code, configuration files, virtual machine monitor kernels, etc., into a complete programmable image package, and adding secure hash signatures and configuration fingerprints to ensure image integrity and trusted boot.

[0147] Therefore, the emission process in step E2 acts as the compiler backend, which sinks the configuration data of the hardware resources generated by the processing and renders it into the source code, configuration files and final deployable image expected by the specific virtualization platform.

[0148] The target file in this application embodiment will be automatically packaged with the Bootloader or firmware image into a binary file that can be directly burned, and will also include an SHA (Secure Hash Algorithm) signature and configuration fingerprint to facilitate production line verification and OTA (Over-the-Air Technology) upgrades.

[0149] The virtual machine monitor in this application embodiment calls a specified lease ID via Hypercall / SMC (Secure Monitor Call), which enables atomic switching of I / O (input / output) or memory mapping within the security boundary, providing support for scenarios such as diagnostics and resource sharing. If an anomaly occurs, the rollback script will immediately restore the original configuration and record all changes in the audit log to meet functional safety and compliance requirements.

[0150] Therefore, the tool in this application upgrades the traditional, cumbersome, and error-prone manual register configuration into an automated pipeline that is compileable, verifiable, and mass-producible, significantly reducing manpower input and greatly improving delivery reliability.

[0151] It should be noted that the embodiments of this application can be applied to various partition management programs such as Bao, Jailhouse, and Xen, and can automatically synthesize configuration files and initialization C code in formats such as JSON, C language code, and DTB (Device Tree Blob).

[0152] In one optional implementation of this application, before compiling the intermediate representation structure into a machine-loaded target file in step 106, the method may further include: verifying the intermediate representation structure to obtain a corresponding verification result; the verification includes at least one of the following verifications: format and reference integrity verification, address and overriding verification, permission consistency verification, interrupt request verification, direct memory access verification, input / output memory management unit verification, timing and barrier verification; if the verification result is successful, the compilation of the intermediate representation structure into a machine-loaded target file is triggered.

[0153] Before compiling the intermediate representation structure into a machine-loadable object file in step 107, this embodiment of the application performs multi-dimensional compliance verification on the intermediate representation structure (covering at least one of format and reference integrity verification, address and overriding verification, permission consistency verification, interrupt request verification, direct memory access verification, input / output memory management unit verification, and timing and barrier verification), and decides whether to trigger the subsequent compilation process based on the verification results. Since the compilation operation from the intermediate representation structure to the object file is only executed when the verification result is successful, it can intercept problems such as format errors, address conflicts, permission contradictions, interrupt configuration anomalies, DMA access out of bounds, improper IOMMU rules, and missing timing / barrier instructions from the source. This avoids incorrect configurations being compiled into executable hardware control data, which not only improves the correctness and security of subsequent compilation products, but also reduces the risk of functional abnormalities and isolation failures caused by configuration errors in the virtualization environment, further improving the reliability and compliance of the entire process.

[0154] This application employs a pass-based static verification method to verify the intermediate representation structure. This verification method is based on interval arithmetic and SAT (Boolean Satisfiability Problem) / SMT (Satisfiability Modulo Theories) to perform minute-level overall verification of the verification items. Furthermore, it effectively eliminates the verification bottleneck of large-scale SoCs (System-on-Chips) through partitioning and parallelization.

[0155] Pass-based static validation is a method that embeds validation logic into the configuration generation process. It defines a series of validation rules and automatically executes rule checks during configuration generation to ensure that each transformation conforms to security constraints. Specifically, range arithmetic is used to analyze numerical ranges such as memory address ranges and permission ranges to determine if there are overlaps or out-of-bounds errors; SAT is used to determine if there are variable assignments in logical formulas that satisfy the conditions; and SMT, as an extension of SAT, supports integer, real number, and bit vector theories, enabling the expression of more complex hardware constraints.

[0156] This verification mechanism can execute verification items sequentially according to predetermined steps. Each step corresponds to specific verification content and outputs. The specific process is as follows: Step F1, Format and Reference Integrity Verification: Check the format specifications and resource reference integrity of the intermediate representation structure to ensure there are no format errors or missing references, and generate the first verification report and issue list.

[0157] Step F2, Address and Overlay Verification: Based on interval arithmetic analysis of memory address range conflicts, aliases and overlays, investigate address overlap, out-of-bounds issues and generate a second verification report.

[0158] Step F3, Permission Consistency Verification: Verify whether the permission configuration complies with the principle of least privilege, ensuring that permission attributes such as XN (Execute Never), RO (Read Only), and W1C (Write 1 to Clear) are consistent. At the same time, check for cross-domain write operations or unauthorized extended DMA (Direct Memory Access) permissions, and generate a third verification report.

[0159] Step F4, Interrupt Request Verification: Verify the legality of the interrupt route, ensure that the mapping relationship from the interrupt source to the target vCPU (Virtual Central Processing Unit) is unique, and that the interrupt priority and affinity parameter configurations are valid, and generate the fourth verification report.

[0160] Step F5, Direct Memory Access Verification and Input / Output Memory Management Unit Verification: Check the validity of the SMMU (System Memory Management Unit) flow table, CB (Context Bank) or bus whitelist, and verify the correctness of the attribute configuration of MSI (Message Signaled Interrupt) and doorbell interrupt area, and generate the fifth verification report.

[0161] Step F6, Timing and Barrier Verification: Verify that programming sequence primitives such as wait, poll, and depend_on have no circular dependencies or logical gaps. At the same time, check the accuracy of the insertion positions of DSB (Data Synchronization Barrier), ISB (Instruction Synchronization Barrier), TLBI (Translation Lookaside Buffer Invalidate), and cache operation instructions to ensure consistency between memory access order and instruction execution timing in a multi-core environment, and generate the sixth verification report.

[0162] If all six verification reports (from the first to the sixth verification report) show successful verification results, a successful verification result can be obtained.

[0163] The method in this application embodiment may further include: if the verification result is a verification failure, searching in the mapping relationship between hardware resources and policies according to the hardware resource that triggered the error to obtain the violation policy item corresponding to the hardware resource that triggered the error; obtaining the target node corresponding to the hardware resource that triggered the error from the register semantic structure according to the index information of the node in the hardware resource category; and analyzing the violation policy item and the target node to obtain the repair suggestion corresponding to the faulty hardware resource.

[0164] When a hardware resource violation is detected, the error information can be captured first, and the error identifier can be extracted from it. These error identifiers specifically include the type of hardware resource that triggered the error (such as DMA device, IRQ interrupt, register, etc.), the hardware resource identifier (such as device ID, physical address, interrupt number, register address), and the error type (such as address conflict, permission violation, configuration mismatch, etc.).

[0165] Next, a query operation can be performed on the mapping relationship between hardware resources and policies. Based on the hardware resource identifier that triggered the error, the corresponding violation policy item in the mapping relationship can be found.

[0166] Furthermore, the target node can be obtained from the register semantic structure based on the node's index information in the hardware resource category. Specifically, the index of the hardware resource (such as address, status bits, configuration parameters) is used for querying, and the register semantic structure continuously tracks the latest state of the hardware resource (such as register writes, configuration changes, etc.). Therefore, the final output target node can accurately reflect the actual state of the current hardware resource.

[0167] The analysis of the violating policy items and target nodes will fully incorporate various dynamic factors, including the current working status and configuration parameters of hardware resources, environmental variables and load conditions during system operation, historical operation records and configuration change logs, hardware health status and error logs, as well as the difference between the expected behavior of the policy item and the actual status of the target node, in order to uncover the underlying causes of the errors.

[0168] Based on the analysis results, targeted remediation suggestions are generated. First, the root cause of the error is accurately identified, such as incorrect policy configuration, resource conflicts, or permission mismatches. Then, specific remediation solutions are generated, such as "adjusting the DMA address range in policy item A" or "modifying the interrupt routing configuration." Detailed steps and parameter suggestions for the remediation operation are also provided, and finally, a complete remediation suggestion is output for developers or automation tools to execute.

[0169] This application embodiment can synchronously feed back error location results and repair suggestions to users or upper-level systems, making it convenient for relevant personnel to know the problem situation in a timely manner; at the same time, it will record error information, location process and repair suggestions in detail in the log system, and will also update error statistics and system health status in the future, providing data support for system maintenance and subsequent optimization.

[0170] Additionally, it should be noted that the partitioning policy data in this application embodiment may include: static policy and / or dynamic policy.

[0171] Among them, the static strategy takes determinism and verifiability as its core objectives and is suitable for scenarios with stringent requirements for stability and security, such as security islands, functional safety domains, and hard real-time tasks. Its execution process starts from RDL (Register Description Language) / DSL, generates a unified IR (Intermediate Representation) structure, and after verification of compliance, automatically synthesizes configuration files adapted to different partition management programs such as Bao, Jailhouse, and Xen, as well as platform initialization C code and DTB. Finally, it links with the Bootloader and packages it into a programmable image.

[0172] The dynamic policy aims to switch a limited set of memory / IO mappings or IRQ routes on demand at runtime. It is suitable for scenarios requiring dynamic resource allocation adjustments, such as cross-domain buffer sharing, temporary device reuse, and online diagnostics / firmware upgrades. It first generates a set of capability-bounded candidate mappings, then uses Hypercall / SMC (Secure Monitor Call) calls to invoke the mapping lease interface to activate and deactivate the policy. Simultaneously, the toolchain automatically generates rollback scripts and shadow tables for rapid recovery in case of anomalies. Furthermore, the dynamic policy incorporates multiple security safeguards, including read-only / write-only window limits, DMA capability checks, doorbell / shared memory handshake mechanisms, maximum lifetime (TTL) control, and event audit logging, ensuring the security and traceability of the dynamic adjustment process.

[0173] Therefore, embodiments of this application can support static configuration at boot-time and controlled adjustments at runtime (such as I / O sharing / doorbell interrupt / shared memory).

[0174] In this embodiment of the application, the upper interface of the development tool, i.e. the output product of the tool, is a standardized deliverable provided by the tool to upper-layer applications or developers, which can be directly used or integrated by them.

[0175] The upward interface specifically includes: unified dialect, unified mode, or generated ABI (Application Binary Interface), etc.

[0176] Specifically, the generated ABI includes: the DTS (Device Tree Source) field specification configuration structure and standardized C language interface functions (such as hardware virtualization lease activation functions and interrupt routing configuration functions) encapsulated based on HAL (Hardware Abstraction Layer). Unified dialects include: YAML, JSON, MLIR, etc. These unified dialects provide standardized data interaction formats for upper-layer applications and developers, facilitating data transmission and understanding.

[0177] The downlink interface is the input data for the development tools. It includes RDL / IP-XACT field mapping, MMU / MPU attribute compatibility matrix, dangerous sequence annotations (such as read-modify-write, write-after-write, read-clear, memory barriers, etc.), and pluggable architecture configuration data. These are the input specifications, configuration data, and extension mechanisms that the development tools rely on to understand the specific behavior of the underlying hardware, and can adapt to different hardware platforms and architectures.

[0178] In summary, the partition management program development method of this application embodiment automatically processes the input data and generates target files that can be directly loaded and executed by the target machine. Therefore, this application embodiment can significantly reduce manual processing steps, thereby effectively reducing the labor costs in the development process.

[0179] Furthermore, the method in this application integrates input data (including chip register description data, behavior specification data, architecture configuration data, and partitioning strategy data) into a unified intermediate data structure. Because this intermediate data structure can extract semantic information representing functional partitions based on resource, permission, and timing relationships, it can mask the underlying differences between different chips and architectures, thereby achieving accurate representation of functional partition semantics. Therefore, this application embodiment is applicable to multiple chips and architectures, and significantly improves the adaptability of partition management program development.

[0180] Furthermore, this application's embodiments address the significant differences in MMU / MPU, privilege levels, and interrupt systems among architectures such as ARM Cortex-A / R / M (Advanced RISC Machine / Real-time RISC Machine / Microcontroller RISC Machine), RISC-V (Reduced Instruction Set Computer Version 5), and TriCore (Tri-Core Processor). By extending the architecture configuration data, heterogeneous semantics are reduced to a unified intermediate data structure.

[0181] Secondly, in this application embodiment, the static structure contained in the chip's register description data and the behavioral semantics of the chip's behavioral specification data are aligned to the register node to construct a register semantic structure and a virtual register structure to support the attribute / side effect annotation and incremental update of tens of thousands of registers.

[0182] Furthermore, in terms of correctness, pass-based static verification is used to perform minute-level overall verification of address / permission / IRQ conflicts, timing barriers and DMA privilege escalation, and the bottleneck of large SoC is eliminated through partitioning and parallelization; On the generation side, a dual-stack MMU / MPU sinking process is designed: the same IR can produce both Stage-2 page tables and MPU region tables, and the corresponding region merging / splitting algorithm reduces entries and reduces distortion of overlay and permissions; It supports various partition management programs, using plug-in-based deployment processing and template version management to interface with multiple partition management programs such as Bao / Jailhouse / Xen, and upstream regression ensures compatibility.

[0183] During runtime, limited changes are made within the security boundary through controlled dynamic "mapping leases" (shadow tables, atomic switching, rollback, and full auditing); to improve scalability and performance, parallel verification and layered caching of intermediate data structures are provided.

[0184] In terms of engineering compliance, we have built-in MISRA-C (MotorIndustry Software Reliability Association C) / ISO 26262 (Road Vehicles - Functional Safety) checks and CI / CD (Continuous Integration / Continuous Deployment) + HIL (Hardware-in-the-Loop) integration. For collaboration and asset reuse, we have built a versioned register repository, automatic diffing and migration patches, and a closed-loop error correction system with "locatable diagnostics + suggested fixes." The following sections will elaborate on our design trade-offs, error correction strategies, and verification paths to address these challenges.

[0185] 3.4.1 Differentiated Construction of MMU and MPU Under a unified intermediate data structure, the embodiments of this application simultaneously support two types of memory protection / virtualization paths: page-based MMU and segment-based MPU, and enable the generated objects (generated target files) to be directly used for the startup and (controlled) runtime changes of the partition management program.

[0186] Table 1 shows the differences between the MMU and MPU.

[0187] Table 1

[0188] This application provides two hardware resource partitioning strategies: static and dynamic. The static strategy, the default strategy, aims at determinism and verifiability. Its execution pipeline is as follows: System RDL or DSL is converted into a unified IR, verified, and then initialization C code or DTB for platforms such as Bao / Jailhouse / Xen is generated. This code is then linked with the bootloader and flashed. It is suitable for scenarios such as security islands, functional safety domains, and hard real-time tasks. The dynamic strategy is a controlled strategy that aims to switch a limited set of memory / I / O mappings or IRQ routes on demand at runtime. Its core mechanism is as follows: First, a set of capability-bounded candidate mappings identified by IDs is generated. Then, Hypercall / SMC calls the mapping lease interface to complete the activation and deactivation of the mappings. The tool generates rollback scripts and shadow tables for anomaly recovery. This dynamic strategy is equipped with multiple guardrails such as read-only / write-only windows, DMA capability checks, doorbell / shared memory handshakes, maximum lifetime, and event audit logs. It is suitable for scenarios such as cross-domain buffer sharing, temporary device reuse, and online diagnostics / firmware upgrades.

[0189] This application's embodiments support differentiated adaptations for various multi-core configurations. The SMP (Symmetric Multi-Processing) tool expression supports CPU set binding via hvc.assign_cpu (Hypervisor Call - Assign CPU), focusing on TLB shoot-down (Translation Lookaside Buffer Shoot-down), IPI / SGI (Inter-Processor Interrupt / Software Generated Interrupt) injection, and the maintenance of shared cache consistency domains. AMP (Asymmetric Multi-Processing) adopts a tool expression that binds disjoint CPU sets to each VM, implementing communication based on a doorbell / shared memory mechanism, focusing on cross-core clock reference alignment, heterogeneous peripheral affinity matching, and bandwidth quota management. The Lockstep configuration tool expression treats Lockstep dual-cores as a logical single core for allocation, with core concerns covering interrupts / ... Exception mirroring, read-only code mirroring, write operation idempotency, and error consistency injection; Cluster / NUMA (Non-Uniform Memory Access) tools are expressed by carrying cluster attributes in IR to achieve memory / interrupt affinity-first local allocation, focusing on cross-cluster interrupt latency optimization, Cache / LLC (LastLevel Cache) resource contention resolution, and bandwidth scheduling strategies.

[0190] This application embodiment refers to the ARM real-time architecture processor core (such as ARMv8). R's Cortex R52) and ARM application architecture processor cores (such as ARMv8) A's Cortex The A53 / A55 implementations are differentiated. R52 represents the secure real-time MPU route, while A53 / A55 represent the general-purpose computing MMU route.

[0191] Table 2 shows the ARMv8... R's Cortex R52 and ARMv8 A's Cortex Examples of architecture configuration data corresponding to A53 and A55 respectively.

[0192] Table 2

[0193] For Cortex The R52 architecture enables mpu.region_planner, limiting the number and priority of Regions; outputs: mpu_regions.c / h, linker.ld, icu_config.c, device passthrough whitelist; verification: region coverage ≥ 99%, conflict = 0, critical areas read-only / execute attribute locked.

[0194] For Cortex For A53 / A55 architecture, enable mmu.s2_seed and gicv3.route Pass, with smmu.stream optional; Outputs: s2_tables.c / h, gicv3_init.c, dtb, Bao / Jailhouse target configuration; Verification: Page range coverage ≥ 99%, alias / remapping conflicts = 0, IRQ path consistency passed.

[0195] Comparative analysis shows that R52 represents the "MPU + determinism" security / real-time route; A53 / A55 represents the "MMU + throughput" general virtualization route.

[0196] The following is a comparison of the memory and permission handling of MMU and MPU.

[0197] The ARMv8-A architecture employs an MMU to implement two-level address translation. Stage-1 (the first stage) involves the operating system maintaining page tables (TTBRx_EL1 / MAIR_EL1) to translate virtual addresses (VA) to intermediate physical addresses (IPA). Stage-2 (the second stage) involves the virtual machine monitor maintaining secondary page tables (VTTBR_EL2 / VTCR_EL2) to translate intermediate physical addresses (IPA) to physical addresses (PA). This architecture features VMID / ASID / TLB tagging, attribute overlay (WB / WT / Device), and SMMU (System Memory Management Unit) DMA isolation. Corresponding tool outputs include s2_tables.c / h, Bao / Jailhouse / Xen configuration, DTB fragments, and SMMU flow tables.

[0198] The ARMv8-R architecture employs an MPU to implement two levels of memory protection. The EL1-MPU is managed by the operating system, defining memory read / write / execute permissions, shareability, and MAIR (Memory Attribute Indirection Register) indexes through configuration of the Protection Region Base Address Register (PRLAR) and Protection Region Limit Address Register (PRLAR). The EL2-MPU is managed by the Virtual Machine Monitor (HV), implementing homogeneous configuration based on HPRBAR / HPRLAR to perform secondary protection for the Virtual Machine (VM). This architecture features address-free translation, 64-bit granular control, prohibition of region overlap, and stricter rules for combining EL1 / EL2 attributes. Corresponding tool outputs include mpu_regions.c / h, linker scripts with fixed load addresses, a whitelist of peripheral windows, and boot sequences containing serial ports, timers, GIC-Lite, and NVIC.

[0199] The tool uses a unified IR to abstractly describe memory blocks using mem.segment{attrs}. For the ARMv8-A MMU architecture, the abstraction of memory blocks is pushed down to page table construction logic. For the ARMv8-R MPU architecture, the abstraction of memory blocks is pushed down to Region planning and conflict resolution logic, specifically covering operations such as Region minimization, merging, and splitting, thereby achieving unified adaptation for the two architectures.

[0200] The following section compares and explains the virtualization and interrupts of the MMU and MPU. Specifically, ARMv8... A: GICv3 / v4 supports the Virtual Interface (GICV). HV can be injected into the list register or passed through the physical interface (but trapping / emulation of shared registers is still required). ARMv8 R: Retain two interrupt lines (fast interrupt request or interrupt request), which can directly assign interrupt requests to objects and reserve fast interrupt requests for HV; HV needs to perform group and routing management on the GIC's Distributor (Generic Interrupt Controller Distributor) / Redistributor (Generic Interrupt Controller Redistributor), and perform selective traps on the shared ICC (Interrupt Controller CPU Interface) register.

[0201] Regarding multi-core consistency, for R52 cores, the MPU is an in-core register, deployed on a per-core basis. Cores within the same address space (AS) need to synchronize updates from the Virtual Memory Protection Unit (vMPU) to the Physical Memory Protection Unit (PMPU) via IPI (Inter-Processor Interrupt) / message queues. The configuration of its Shareability domain depends on the platform, typically requiring Outer-shareable to ensure cross-core consistency. Meanwhile, the Profile function on the tool side can treat Lockstep dual-cores in Lockstep / Split-mode as logical single-core resources for binding. For A53 / A55 cores, the page table is stored in memory. The master core can pre-arrange page tables for slave cores, achieving inter-core page table consistency through the TLB shoot-down mechanism. Multi-core consistency for this type of core relies on the virtual interrupt (vIRQ) affinity configuration of GICv3 / ITS and NUMA / Cluster. Affinity labeling.

[0202] Regarding devices and peripherals, the A53 / A55 core channels map physical peripherals to intermediate physical addresses; virtual peripherals trigger S2 Fault (Stage 2 Fault) → HV emulation; general-purpose timers provide CNTVCT (Counter Virtual Count) virtual time base. Peripherals on the R52 core channels are typically physically pass-through (MPU window); shared peripherals are shared via read-only registers + doorbell / shared memory handshake.

[0203] Interrupt virtualization schemes include two modes: list register injection and GIC direct injection. Scheme A (list register injection) is a general scheme. Its execution flow is that the physical IRQ first enters EL2, and then is converted into a virtual interrupt (vIRQ) and sent to EL1 by writing to the list register (LR). The advantage of this scheme is that it supports fine-grained arbitration of interrupts, but there is a performance overhead of VM-exit and register emulation. Scheme B (direct injection) is more suitable for R52 cores. Its configuration includes enabling Group0 / 1 interrupt grouping through the GICD.CTLR (General Interrupt Controller CPU Interface Group0 Enable Register) register; and the guest OS enables Group0 interrupt grouping through ICC_IGRPEN0_EL1 (Interrupt Controller CPU Interface Group0 Enable Register, EL1 level). The EL1 register manages Group 0 (IRQ, Interrupt Request) interrupts; the HV (Hypervisor) handles Group 1 (FIQ, Fast Interrupt Request) interrupts, and selectively traps shared ICC (Interrupt Controller CPU Interface) registers such as PMR / RPR / CTLR (Priority Mask Register / Reserved Priority Register / Control Register). The advantage of this approach is that it achieves interrupt latency close to that of bare metal, while using a whitelist mechanism and domain isolation measures to protect shared registers and interrupt affinity.

[0204] This solution establishes clear constraints for MPU region planning and conflict resolution in the R52 core, requiring regions to be non-overlapping, meet 64B alignment requirements, and apply stricter rules when EL1 / EL2 attribute combinations are used. Regarding region merging and splitting strategies, it stipulates that read-only Hypervisor regions can share an EL2 region with object windows without reducing privileges, while prohibiting any overlap of executable regions. The goal of the planning is to cover the Hypervisor image, common interfaces, BSS (Block Started by Symbol), device windows, and VMCB (Virtual Machine Control Block) with the fewest possible regions. The implementation logic on the tool side involves recording the desired regions through the vMPU (virtual table), with the decision-maker performing interval merging, sorting, and conflict checking, and then pushing the final planning result down to the PMPU (Physical Memory Protection Unit) of each core. Cross-core synchronization relies on the main core to generate relevant entries and sends them as IPI (Inter-Processor Interrupt) messages (including AS (Address Space) messages). This is achieved by receiving the information from the core (space type / ID + region description information) and then writing it to the local PMPU.

[0205] This application's embodiments adopt a static strategy by default: all memory, I / O and IRQ mappings, device ownership and access permissions (corresponding to the MMU's S2 page table or the MPU's Region table, GIC routing, and SMMU / PPU's DMA whitelist) are fixed during compilation / before power-on. These structures do not change after startup to ensure determinism, verifiability, and audit traceability. When runtime adjustments are necessary, a controlled dynamic policy is implemented: During the build phase, the tool pre-generates and signs a set of "candidate mappings" (assigning unique lease IDs). Each candidate explicitly lists the effective physical / intermediate address range, I / O window, IRQ number and affinity, read / write / executable attributes, allowed DMA capabilities, dependent barriers and rollback scripts, and sets a maximum effective duration (TTL) and application count limit. At runtime, only guests or management domains are allowed to request the activation / revocation of these existing candidates via Hypercall / SMC. The management program performs "capability boundary and conflict detection" (address aliasing, permission floating, IRQ contention, cache / barrier timing) on ​​the requests. Upon successful detection, the mapping is atomically loaded and audit logs and configuration fingerprints are recorded. Upon expiration or revocation, a rollback is executed. The system explicitly prohibits the creation of arbitrary executable mappings outside the candidate set and the expansion of DMA. High-risk operations such as access scope, cross-domain write privilege escalation, or unauthorized changes to interrupt affinity must all be implemented within the isolation barrier of the read-only / write-only window and the doorbell / shared memory handshake. This mechanism is mainly used for low-risk, time-constrained operation and maintenance scenarios, such as temporarily sharing the log collection ring buffer with the diagnostic domain, opening a restricted register visibility window for online diagnostics, briefly reusing redundant peripherals when the main device fails, or opening a firmware upgrade security channel only during upgrades. This satisfies operation and maintenance needs without compromising real-time performance and strong isolation.

[0206] The outputs of the tool differ significantly across architectures: For the R52 core (MPU architecture), the output includes mpu_regions.c / h (containing the fill sequence for the PRBAR / HPRBAR, PRLAR / HPRLAR registers), linker.ld (defining the fixed offsets between the image and private structures), icu_gic_init.c (configuring interrupt groups and affinity), as well as a device whitelist and doorbell / shared memory description file; For the A53 / A55 core (MMU architecture), the output includes s2_tables.c / h, gicv3_init.c, the SMMU Stream Table, and target configuration files and DTS / DTB fragments adapted for Bao / Jailhouse / Xen.

[0207] Taking UART0 (Universal Asynchronous Receiver / Transmitter 0) as an example, this embodiment describes the peripheral initialization process as a device programming sequence. First, an enable bit is written to the UART0 control register to turn on the clock; then, within a 10ms timeout limit, the READY bit of the UART0 status register is polled until it reaches 1; next, the target baud rate parameter is written to the baud rate register; finally, the START bit of the UART0 control register is set to start transmission and reception. For registers that may trigger side effects such as "read-modify-write (RMW)," "posted-write," and "read-clear," this embodiment automatically inserts data / instruction barriers during the generation phase to ensure that timing and consistency meet hardware requirements.

[0208] Virtualization layout and execution protocol representation: The CPU binding, memory regions, device passthrough, virtual interrupt routing, and shared memory strategies of the guest virtual machine are structurally described using a unified configuration dialect in this application embodiment. During the generation phase, these are converted into device tree fragments, configuration JSON, and initialization C code required by the corresponding platform. This description does not depend on a specific ISA or SoC; during generation, it automatically selects the MMU (page table constructor) or MPU (region planning) path based on the architecture configuration data and completes conflict detection and validity verification.

[0209] The tool outputs different features depending on the hypervisor platform. For the Bao platform, the output is a platform file containing configuration information such as vCPU binding, memory regions, MMIO / IRQ lists, and shared memory. For the Jailhouse platform, the output is a cell.c file, which describes the allocation rules for hardware resources such as CPU, memory, PCI, and IRQ. For the Xen (Dom0-less) platform, the output is a DTS fragment, covering CPU pool, xen,reg (Xen registers), interrupts, and device ownership. All platforms also generate common C code files such as initialize_platform_hardware (platform hardware initialization function), mmu_mappings.c / h (MMU mapping configuration files), and gic_config.c (GIC interrupt controller configuration file). These outputs can then be linked or packaged with the bootloader to generate a directly programmable binary file.

[0210] In summary, the embodiments of this application can not only derive the register structure based on the parsing of the chip's register description data and the chip's behavioral specification data, but also formalize the initialization protocol (sequential / polling / dependency), thus solving the semantic gap problem.

[0211] Furthermore, the embodiments of this application adopt the MLIR / HVC compiled generation scheme, which replaces the traditional scripts / templates with compiler pipelines, and supports verification, optimization and multi-target backend.

[0212] Furthermore, embodiments of this application abstract the differences between the modes of MMU / MPU, GICv3 / AIA, and EL / HS (Exception Level / Hypervisor Secure mode) through architecture configuration data, and achieve automatic selection of target policies.

[0213] Furthermore, this application embodiment provides a virtual register view for pass-through / shared devices based on register permission pruning and aliasing mechanisms, thereby improving isolation and controllable sharing capabilities.

[0214] No, the embodiments of this application follow the principle of correct construction, verifying addresses, permissions, IRQs and dependencies before generation to reduce the risk of startup debugging failures and online rollback.

[0215] Therefore, the embodiments of this application can significantly reduce adaptation costs and cycles, and one model can cover multiple SoCs or even multiple Hypervisor architectures; it can expose structural design errors in advance to increase verifiability, and directly discover configuration conflicts during the generation stage; at the same time, the structured and modular system development mode can improve the determinism and security of the system, ensure that the semantics of static partitions are not destroyed, and has the characteristics of low maintenance costs and high reusability. Platform upgrades only require updating the input data to regenerate.

[0216] The effectiveness of the embodiments in this application can be verified through multiple embodiments.

[0217] In Example 1, based on the ARMv8-A+Bao architecture, the SystemRDL, GICv3, SMMU, and Timer Peripheral RDL of the SoC are input. A strategy of binding two VMs with 4×A531:1, direct access of the Linux partition to UART0 / ETH, and direct access of the RTOS partition to SPI is adopted. Finally, BaoJSON, DTSI fragment, gic_init.c, and mmu_stage2.c are produced and packaged into an image. The effect of initialization is completed within 200ms after power-on, VMs do not interfere with each other, and interrupt injection delay is ≤3µs.

[0218] Example 2 is based on the RISC-V+XenHyperlaunch architecture. It takes inputs (Advanced Interrupt Architecture / Platform-Level InterruptController Distribution List) and HS / H extensions (Hypervisor Secure / Hypervisor Extension) to complete the architecture adaptation. At the same time, it adopts the strategy of Dom0-less (no management domain), static partitioning of cpupools (CPU pools), and direct access of guest RTOS (real-time operating system) to GPIO / Timer (general-purpose input / output / timer) to produce DTB, Xen configuration, and platform initialization C code, completes the path configuration from AIA source interrupt to vIRQ, and realizes inter-VM notification with the help of doorbell interrupt.

[0219] Example 3 is designed for automotive-grade MCU+MPU mode. It takes MPU / peripheral RDL as input, adopts the strategy of static allocation of memory segments of single-core / multi-core MCU and peripheral MMIO, and supports devices sharing read-only registers, and produces startup linker script, MPU table generation file and peripheral initialization sequence to meet the isolation requirements of ISR determinism and functional safety.

[0220] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to this application.

[0221] It should be noted that the partition management program development method provided in this application embodiment can be executed by a partition management program development device, or a control module in the partition management program development device for executing the partition management program loading development method. This application embodiment uses the execution of the partition management program loading development method by a partition management program development device as an example to illustrate the partition management program development method provided in this application embodiment.

[0222] Reference Figure 4 The diagram illustrates the structure of a development apparatus for a partition management program according to an embodiment of this application. The apparatus includes the following modules: The receiving module 401 is used to acquire input data; the input data includes: chip register description data, chip behavior specification data, chip architecture configuration data, and partitioning strategy data; The semantic structure generation module 402 is used to generate the register semantic structure of the chip based on the register description data of the chip and the behavior specification data of the chip. The virtual structure generation module 403 is used to determine the virtual register structure corresponding to the virtual machine in the partitioning strategy data based on the register semantic structure. The strategy determination module 404 is used to determine a target strategy that matches the architecture configuration data of the chip based on the partitioning strategy data. The intermediate structure generation module 405 is used to generate an intermediate representation structure based on the register semantic structure, the virtual register structure, and the binding relationship between the target policy and the nodes in the register semantic structure; the intermediate representation structure is used to represent the hardware resources allocated to the virtual machine, the permissions and timing corresponding to the hardware resources; The compilation module 406 is used to compile the intermediate representation structure into a machine-loadable target file; the target file is a configuration file of the partition management program, or the target file is a component of the executable file of the partition management program, and the target file follows the configuration rules of the partition management program.

[0223] Optionally, the semantic structure generation module includes: The structure parsing module is used to parse the register description data of the chip to obtain register structure information; The behavior parsing module is used to parse the behavior specification data of the chip to obtain register behavior information; The semantic modeling module is used to generate the register semantic structure of the chip based on the register structure information and the register behavior information.

[0224] Optionally, the semantic modeling module includes: The node processing module is used to construct nodes for the registers in the register structure information or the bit fields in the registers, and to aggregate the nodes according to hardware resources; The edge building module is used to construct edges based on the relationships between different nodes; The constraint addition module is used to add corresponding constraint information to the node and the edge based on the attribute information of the register in the register structure information and the timing information in the register behavior information; The index building module is used to build an index of the node in the address range tree and to build an index of the node to the hardware resource category.

[0225] Optionally, the virtual structure generation module includes: The allocation module is used to allocate target hardware resources to the virtual machine according to the partitioning policy data; the hardware resource category to which the target hardware resources belong corresponds to a target register; The permission determination module is used to determine the permissions corresponding to the target register; A mapping module is used to map the target register to a virtual register; A virtual register structure generation module is used to generate the virtual register structure corresponding to the virtual register; the virtual register structure is used to represent the virtual registers allocated to the virtual machine, the permissions and timing corresponding to the virtual registers.

[0226] Optionally, the strategy determination module includes: The matching module is used to match the first architecture corresponding to the strategy in the partitioning strategy data with the second architecture in the architecture configuration data of the chip to obtain the candidate strategy that is successfully matched. The ranking module is used to rank the candidate strategies according to ranking indicators to obtain ranking results; the ranking indicators include: resource usage indicators and / or functional integrity indicators; optionally, security priority / affinity weights can also be introduced as optional ranking indicators to prioritize the more secure scheme when functional integrity is equivalent.

[0227] The selection module is used to select a target strategy from the sorting results.

[0228] Optionally, the apparatus further includes: a binding module, configured to construct a binding relationship between the target policy and nodes in the register semantic structure; The binding module includes: The first configuration module is used to configure the attribute information of the memory management node in the register semantic structure according to the virtual machine memory segment information in the target policy; or The second configuration module is used to configure the attribute information of the device management node in the register semantic structure according to the device pass-through sharing mode information in the target strategy; or The third configuration module is used to configure the attribute information of the interrupt control node in the register semantic structure according to the interrupt target and interrupt priority information in the target strategy; or The fourth configuration module is used to configure the attribute information of the DMA control node in the register semantic structure according to the system memory management unit flow table or bus whitelist information in the target strategy.

[0229] Optionally, the compilation module includes: The conversion module is used to convert the intermediate representation structure into hardware resource configuration data based on the architecture configuration data of the chip. The encapsulation module is used to encapsulate the configuration data of the hardware resources into a machine-loadable target file according to the format specifications of the partition management program.

[0230] Optionally, the device further includes: The verification module is used to verify the intermediate representation structure before compiling it into a machine-loadable target file, and obtain a corresponding verification result. The verification includes at least one of the following verifications: format and reference integrity verification, address and overriding verification, permission consistency verification, interrupt request verification, direct memory access verification, input / output memory management unit verification, and timing and barrier verification. If the verification result is successful, the compilation module is triggered to compile the intermediate representation structure into a machine-loadable target file.

[0231] Optionally, the device further includes: The policy positioning module is used to search in the mapping relationship between hardware resources and policies based on the hardware resource that triggered the error when the verification result is verification failure, and obtain the violation policy item corresponding to the hardware resource that triggered the error. The node location module is used to obtain the target node corresponding to the hardware resource that triggered the error from the register semantic structure based on the node's index information in the hardware resource category. The analysis module is used to analyze the violation policy item and the target node to obtain repair suggestions for the hardware resources that triggered the error.

[0232] The development apparatus for the partition management program in this application embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network-attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This application embodiment does not impose specific limitations.

[0233] The development apparatus for the partition management program in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system used.

[0234] The partition management program development apparatus provided in this application embodiment can achieve Figure 1 The various processes implemented by the development device of the partition management program in the method embodiment will not be described again here to avoid repetition.

[0235] Optionally, embodiments of this application also provide an electronic device, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the various processes of the above-described partition management program development method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0236] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0237] Figure 5 A schematic diagram of the hardware structure of an electronic device 1100 according to an embodiment of this application.

[0238] Electronic device 1100 has one or more processors 1102, a control module (chipset) 1104 coupled to at least one of the processors 1102, a memory 1106 coupled to the control module 1104, a non-volatile memory / storage device 1108 coupled to the control module 1104, one or more input / output devices 1110 coupled to the control module 1104, and a network interface 1112 coupled to the control module 1104.

[0239] Processor 1102 may include one or more single-core or multi-core processors, and processor 1102 may include any combination of general-purpose processors or special-purpose processors (e.g., graphics processors, application processors, baseband processors, etc.). In some embodiments, electronic device 1100 can serve as a terminal device, server (cluster), or other device as described in the embodiments of this application.

[0240] In some embodiments, electronic device 1100 may include one or more computer-readable media (e.g., memory 1106 or non-volatile memory / storage device 1108) having instructions 1114 and one or more processors 1102 that are combined with the one or more computer-readable media and configured to execute instructions 1114 to implement modules and thus perform the actions described in this disclosure.

[0241] In one embodiment, the control module 1104 may include any suitable interface controller to provide any suitable interface to at least one of the processors 1102 and / or any suitable device or component communicating with the control module 1104.

[0242] The control module 1104 may include a memory controller module to provide an interface to the memory 1106. The memory controller module may be a hardware module, a software module, and / or a firmware module.

[0243] Memory 1106 may be used, for example, to load and store data and / or instructions 1114 for electronic device 1100. In one embodiment, memory 1106 may include any suitable volatile memory, such as suitable DRAM (Dynamic Random Access Memory). In some embodiments, memory 1106 may include double data rate type quad synchronous dynamic random access memory.

[0244] In one embodiment, the control module 1104 may include one or more input / output controllers to provide an interface to the non-volatile memory / storage device 1108 and (one or more) input / output devices 1110.

[0245] For example, non-volatile memory / storage device 1108 may be used to store data and / or instructions 1114. Non-volatile memory / storage device 1108 may include any suitable non-volatile memory (e.g., flash memory) and / or may include any suitable (one or more) non-volatile storage devices (e.g., one or more hard disk drives, one or more optical disk drives, and / or one or more digital universal optical disk drives).

[0246] The non-volatile memory / storage device 1108 may include storage resources that are physically part of a device on which the electronic device 1100 is mounted, or that can be accessed by the device without being part of the device. For example, the non-volatile memory / storage device 1108 may be accessed via a network via one or more input / output devices 1110.

[0247] One or more input / output devices 1110 may provide an interface for electronic device 1100 to communicate with any other suitable device. Input / output devices 1110 may include communication components, audio components, sensor components, etc. Network interface 1112 may provide an interface for electronic device 1100 to communicate via one or more networks. Electronic device 1100 may wirelessly communicate with one or more components of a wireless network according to any of one or more wireless network standards and / or protocols, such as accessing wireless networks based on communication standards, such as WiFi (Wireless Fidelity), 2G (2-Generation wireless telephone technology), 3G (3-Generation wireless telephone technology), 4G (4-Generation wireless telephone technology), 5G (5-Generation wireless telephone technology), etc., or combinations thereof.

[0248] In one embodiment, at least one of the processors 1102 may be logically packaged with one or more controllers (e.g., memory controller modules) of the control module 1104. In one embodiment, at least one of the processors 1102 may be logically packaged with one or more controllers of the control module 1104 to form a system-in-package. In one embodiment, at least one of the processors 1102 may be integrated with the logic of one or more controllers of the control module 1104 on the same die. In one embodiment, at least one of the processors 1102 may be integrated with the logic of one or more controllers of the control module 1104 on the same die to form a system-on-a-chip.

[0249] In various embodiments, electronic device 1100 may be, but is not limited to, a server, desktop computing device, or mobile computing device (e.g., laptop computing device, handheld computing device, touchscreen device, netbook, etc.). In various embodiments, electronic device 1100 may have more or fewer components and / or different architectures. For example, in some embodiments, electronic device 1100 includes one or more cameras, a keyboard, a liquid crystal display screen (including a touchscreen display), a non-volatile memory port, multiple antennas, a graphics chip, an application-specific integrated circuit (ASIC), and a speaker.

[0250] In the aforementioned electronic device 1100, a main control chip may be used as a processor or control module, sensor data, position information, etc. are stored in a memory or non-volatile memory / storage device, the sensor group may be used as an input / output device, and the communication interface may include a network interface.

[0251] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described partition management program development method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0252] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0253] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0254] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0255] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.< / n> < / n>

Claims

1. A method for developing a partition management program, characterized in that, The method includes: Acquire input data; the input data includes: chip register description data, chip behavior specification data, chip architecture configuration data, and partitioning strategy data; Based on the register description data and behavior specification data of the chip, the register semantic structure of the chip is generated; Based on the register semantic structure, determine the virtual register structure corresponding to the virtual machine in the partitioning strategy data; Based on the partitioning strategy data, a target strategy that matches the architecture configuration data of the chip is determined; An intermediate representation structure is generated based on the register semantic structure, the virtual register structure, and the binding relationship between the target policy and the nodes in the register semantic structure; the intermediate representation structure is used to represent the hardware resources allocated to the virtual machine, the permissions and timing corresponding to the hardware resources; The intermediate representation structure is compiled into a machine-loadable target file; the target file is a configuration file of the partition management program, or the target file is a component of the executable file of the partition management program, and the target file follows the configuration rules of the partition management program.

2. The method according to claim 1, characterized in that, The step of generating the register semantic structure of the chip based on the register description data and the chip behavior specification data includes: The register description data of the chip is parsed to obtain the register structure information; The behavior specification data of the chip is analyzed to obtain register behavior information; The register semantic structure of the chip is generated based on the register structure information and the register behavior information.

3. The method according to claim 2, characterized in that, The step of generating the register semantic structure of the chip based on the register structure information and the register behavior information includes: For the registers or bit fields in the register structure information, construct nodes and aggregate the nodes according to hardware resources; Construct edges based on the relationships between different nodes; Based on the register attribute information in the register structure information and the timing information in the register behavior information, corresponding constraint information is added to the node and the edge; Establish an index for the node in the address range tree, and establish an index for the node to the hardware resource category.

4. The method according to any one of claims 1 to 3, characterized in that, The step of determining the virtual register structure corresponding to the virtual machine in the partitioning policy data based on the register semantic structure includes: Based on the partitioning policy data, target hardware resources are allocated to the virtual machine; the hardware resource category to which the target hardware resources belong corresponds to a target register; Determine the permissions corresponding to the target register; Map the target register to a virtual register; Generate the virtual register structure corresponding to the virtual register; the virtual register structure is used to represent the virtual register allocated to the virtual machine, the permissions and timing corresponding to the virtual register.

5. The method according to any one of claims 1 to 3, characterized in that, The step of determining a target strategy that matches the chip's architecture configuration data based on the partitioning strategy data includes: The first architecture corresponding to the strategy in the partitioning strategy data is matched with the second architecture in the chip's architecture configuration data to obtain a successfully matched candidate strategy; The candidate strategies are ranked according to the ranking criteria to obtain the ranking result; the ranking criteria include: resource usage indicators and / or functional integrity indicators. Select a target strategy from the sorting results.

6. The method according to any one of claims 1 to 3, characterized in that, The binding relationship between the target policy and the nodes in the register semantic structure is constructed through the following steps: Based on the virtual machine memory segment information in the target policy, configure the attribute information of the memory management node in the register semantic structure; or Based on the device pass-through sharing mode information in the target strategy, configure the attribute information of the device management node in the register semantic structure; or Based on the interrupt target and interrupt priority information in the target strategy, configure the attribute information of the interrupt control node in the register semantic structure; or Based on the system memory management unit flow table or bus whitelist information in the target strategy, configure the attribute information of the DMA control node in the register semantic structure.

7. The method according to any one of claims 1 to 3, characterized in that, The step of compiling the intermediate representation structure into a machine-loadable target file includes: Based on the chip's architecture configuration data, the intermediate representation structure is converted into hardware resource configuration data; According to the format specifications of the partition management program, the configuration data of the hardware resources is encapsulated into a target file that is loaded by the machine.

8. The method according to any one of claims 1 to 3, characterized in that, Before compiling the intermediate representation structure into a machine-loadable object file, the method further includes: The intermediate representation structure is verified to obtain the corresponding verification results; the verification includes at least one of the following verifications: format and reference integrity verification, address and overwrite verification, permission consistency verification, interrupt request verification, direct memory access verification, input / output memory management unit verification, and timing and barrier verification; If the verification result is successful, the intermediate representation structure is compiled into a machine-loadable target file.

9. The method according to claim 8, characterized in that, The method further includes: If the verification result is a verification failure, the violation policy item corresponding to the hardware resource that triggered the error is obtained by searching in the mapping relationship between hardware resources and policies based on the hardware resource that triggered the error. Based on the node's index information in the hardware resource category, the target node corresponding to the hardware resource that triggered the error is obtained from the register semantic structure; By analyzing the violation policy item and the target node, repair suggestions are obtained for the hardware resources that triggered the error.

10. A development apparatus for a partition management program, characterized in that, The device includes: The acquisition module is used to receive input data; the input data includes: chip register description data, chip behavior specification data, chip architecture configuration data, and partitioning strategy data; The semantic structure generation module is used to generate the register semantic structure of the chip based on the register description data and the behavior specification data of the chip. The virtual structure generation module is used to determine the virtual register structure corresponding to the virtual machine in the partitioning strategy data based on the register semantic structure. The strategy determination module is used to determine a target strategy that matches the architecture configuration data of the chip based on the partitioning strategy data. An intermediate structure generation module is used to generate an intermediate representation structure based on the register semantic structure, the virtual register structure, and the binding relationship between the target policy and the nodes in the register semantic structure; the intermediate representation structure is used to represent the hardware resources allocated to the virtual machine, the permissions and timing corresponding to the hardware resources; A compilation module is used to compile the intermediate representation structure into a machine-loadable target file; the target file is a configuration file of the partition management program, or the target file is a component of the executable file of the partition management program, and the target file follows the configuration rules of the partition management program.

11. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method as described in claims 1-9.

12. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the method as described in claims 1-9.

Images