Jailhouse-based method, system, and medium for llc allocation

Abstract

The application discloses a LLC allocation method and system based on Jailhouse and a medium, and the method comprises the following steps: formulating a LLC allocation strategy, determining the mapping relationship between each way group of LLC and each scheme, binding a scheme id for each CPU core, filling in a configuration file, writing the LLC allocation strategy as allocation configuration information, and writing the allocation configuration information into a root cell configuration file of Jailhouse, LLC allocation strategy issuing, in the enabling stage of Jailhouse, parsing the root cell configuration file, extracting the allocation configuration information therein, and configuring relevant hardware registers according to the allocation configuration information. The application can overcome the LLC cache conflict between cells, has high memory utilization and good scalability, and can enable Jailhouse to perceive and manage LLC configuration.

Description

Technical Field

[0001] This invention relates to the field of LLC allocation technology, and specifically to an LLC allocation method, system and medium based on Jailhouse. Background Technology

[0002] With the widespread adoption of multi-core SoCs in automotive, industrial control, and communications, systems often need to be divided into multiple runtime domains, running different operating systems simultaneously to handle diverse task requirements. To address resource isolation issues in multi-domain parallelism, embedded virtualization technology is widely used. Jailhouse, an open-source virtualization monitor for embedded platforms, pre-allocates CPU, memory, and peripheral resources to each cell during startup using a static partitioning mechanism, eliminating the need for dynamic scheduling during runtime and achieving low-overhead hardware-level isolation. However, these cells typically still share the on-chip last-level cache (LLC), lacking effective isolation mechanisms. The resulting cache contention leads to frequent data replacements in one domain by another, causing access latency jitter, significantly weakening system determinism and security, and making it difficult to support the stringent real-time and WECT (Worst-Case Execution Time) requirements of mixed-critical applications.

[0003] To address this technical problem, Chinese patent document CN116225982A proposes a scheme for static allocation of LLCs through cache coloring. The basic idea is to pre-calculate the number of LLC colors during Jailhouse startup and virtual machine deployment, statically divide physical pages by color, and then fix the physical memory allocated to different cells to non-overlapping LLC color segments through page table mapping, thereby alleviating cache conflicts to some extent. However, this scheme has the following fundamental drawbacks: Memory utilization is limited: Cache coloring uses "color" as the smallest allocation unit, and the number of colors is determined by the single-way LLC capacity and the system page size, resulting in overly coarse allocation granularity. A cell can only obtain physical pages aligned with a specified color; pages not in the color set are considered unavailable. This causes the actual number of physical pages available to a single cell to be lower than the pre-allocated value declared in the configuration file.

[0004] Poor scalability: As the number of cells increases, the available physical pages of the same color are further diluted, and the overall memory utilization of the system continues to decline, making it difficult to support efficient operation under multi-domain parallelism.

[0005] Lack of hardware-level protection: This method only indirectly constrains cache usage through page table mapping, and essentially still relies on software strategies. It cannot achieve mandatory isolation of LLC at the hardware level, so cross-domain interference may still exist in extreme scenarios.

[0006] In addition, NXP proposed a scheme based on modifying trusted firmware (running at EL3 layer) to issue and enable LLC allocation configuration to the hardware via the Security Monitor Call (SMC) interface. While this method can directly affect hardware registers, it also has the following significant limitations: High implementation complexity: It requires modification of trusted firmware, introducing uncertainties in system integration and subsequent maintenance.

[0007] Insufficient reliability: In the Jailhouse scenario, this method relies on Linux user-space distribution strategies. Jailhouse itself is neither aware of nor able to manage LLC configurations, thus disrupting the overall consistency of its static partitioning architecture. This makes it difficult to meet the stringent security, real-time, and predictability requirements of hybrid mission-critical systems. Summary of the Invention

[0008] The technical problem to be solved by the present invention is to provide a method, system and medium for LLC allocation based on Jailhouse that can overcome LLC cache conflicts between cells, has high memory utilization and good scalability, and enables Jailhouse to perceive and manage LLC configuration.

[0009] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A Jailhouse-based LLC allocation method, applied to an ARM platform supporting DSU, the method comprising: S101. Formulate LLC allocation strategy: Determine the mapping relationship between each way group and each scheme of LLC, and clarify the set of way groups that each scheme is allowed to access; Based on the caching requirements of each cell and the CPU cores used by each cell, bind a scheme ID to each CPU core to ensure that the set of way groups of LLCs that can be accessed by the CPU cores used by different cells do not overlap. S102. Fill in the configuration file: Write the LLC allocation strategy as allocation configuration information and write the allocation configuration information into the Jailhouse root cell configuration file; S103, LLC allocation strategy issuance: During the Jailhouse activation phase, the root cell configuration file is parsed, the allocation configuration information is extracted, and the CLUSTERPARTCR_EL1 register and CLUSTERTHREADSID_EL1 register are configured according to the allocation configuration information.

[0010] Optionally, in step S101, the specific steps for determining the mapping relationship between each way group and each scheme of the LLC, and clarifying the set of way groups that each scheme is allowed to access, include: Optionally, based on the total LLC capacity of the SoC, the number and size of way groups, and the cache requirements of each cell, the LLC allocation ratio for each cell is determined, and the corresponding way group set is allocated to different schemes according to the allocation ratio.

[0011] Optionally, in step S101, the specific steps of binding a corresponding scheme ID to each CPU core according to the caching requirements of each cell and the CPU cores used by each cell include: binding all CPU cores belonging to the same cell to the same scheme ID; for CPU cores belonging to different cells, their respective bound scheme IDs are different, and each scheme ID corresponds to only one CPU core of a cell.

[0012] Optionally, the allocation configuration information includes: the set of way groups that each scheme is allowed to access, represented in the form of a bitmap mask, and the scheme ID information bound to each CPU core.

[0013] Optionally, in step S102, the allocation configuration information is written into the cache_partition field extended in the root cell configuration file, where the cache_partition field is a dedicated field for storing LLC allocation strategies.

[0014] Optionally, in step S103, the cache_partition field of the root cell configuration file is parsed, the bitmap mask is extracted to configure the CLUSTERPARTCR_EL1 register, and the scheme information bound to each CPU core is extracted to configure the CLUSTERTHREADSID_EL1 register.

[0015] Optionally, a cache partitioner module is provided in the Jailhouse hypervisor, which is used to perform step S103.

[0016] Furthermore, the present invention also provides a Jailhouse-based LLC allocation system, including an interconnected microprocessor and a memory, wherein the microprocessor is programmed or configured to execute the above-described Jailhouse-based LLC allocation method.

[0017] Furthermore, the present invention also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the above-described Jailhouse-based LLC allocation method by a processor.

[0018] In addition, the present invention also provides a computer program product, including a computer program or instructions that are programmed or configured to execute the above-described Jailhouse-based LLC allocation method via a processor.

[0019] Compared with the prior art, the present invention has the following main advantages: This invention, by configuring the CLUSTERPARTCR_EL1 and CLUSTERTHREADSID_EL1 registers, enables the LLC allocation strategy to take effect directly at the hardware level. This ensures that the CPU cores used by different cells are physically restricted to cache access within their respective allocated way group sets, preventing bypassing by runtime page tables or scheduling strategies. This fundamentally eliminates LLC cache conflicts between different cells, effectively reduces access latency jitter, and guarantees system determinism and security, meeting the security, real-time, and predictability requirements of hybrid mission-critical systems. Furthermore, this invention integrates the LLC allocation strategy as allocation configuration information into the Jailhouse's root cell configuration file and applies it during the Jailhouse's startup phase. The cell configuration file is parsed, enabling Jailhouse to perceive and manage LLC configurations. This perfectly matches its core architecture of static partitioning and hardware-level isolation, without compromising its static trust boundary. It avoids the complexity and trust chain disruption issues introduced by relying on external components (such as EL3 firmware). Furthermore, this invention does not constrain the allocation of physical pages, but only divides the LLC's waygroups. This helps ensure that the number of available physical pages for each cell matches its pre-allocated value, improving memory utilization. At the same time, as the number of cells increases, this invention can flexibly adjust the allocation combination of waygroups, avoiding the dilution of available resources and providing good scalability. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the execution flow of the method in an embodiment of the present invention. Detailed Implementation

[0021] The present invention will be further described below with reference to the accompanying drawings and specific preferred embodiments, but this does not limit the scope of protection of the present invention.

[0022] As disclosed in this invention, unless the context clearly indicates otherwise, words such as "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. The terms "first," "second," and similar terms used in this invention disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, words such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Words such as "connected" or "linked" are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

[0023] To facilitate understanding, the relevant technical terms that may be involved in this application will be introduced first.

[0024] Hybrid critical systems: A type of computer system that needs to run multiple tasks or subsystems with different criticality levels (such as safety criticality level, real-time criticality level) on an embedded hardware platform.

[0025] Jailhouse: An open-source virtualization hypervisor for embedded platforms. It uses a static partitioning mechanism to pre-allocate CPU, memory, and peripheral resources to each running cell during startup. There is no dynamic scheduling during operation, achieving low-overhead hardware-level isolation.

[0026] Jailhouse hypervisor: The core layer of Jailhouse, responsible for hardware resource management and allocation. This invention adds a module to this layer to implement caching strategy distribution.

[0027] LLC: Last Level Cache is a core cache resource that is usually shared by multiple running domains in a multi-core SoC. In the shared state, cache contention problems are prone to occur.

[0028] WECT: Worst Case Execution Time, a core metric for real-time performance in hybrid mission-critical applications, requiring predictable system execution time with no uncontrollable latency fluctuations.

[0029] DSU: DynamIQ Shared Unit, a core component of the ARM architecture platform, supports hardware-level configuration and management of cache resources such as LLC, and is the hardware foundation for the LLC allocation in this invention.

[0030] scheme: A generic cache partitioning strategy identifier used to mark a group of cache resources (path / group) to implement hardware-level cache ownership and access control. It is a standard concept in the ARM DSU cache partitioning architecture. In the Jailhouse framework, a cell refers to an independent, statically allocated, hardware-isolated runtime domain. Each cell is allocated exclusive physical hardware resources (such as a specific CPU core, memory region, and peripherals) at startup and these resources remain unchanged during runtime, thus achieving deterministic, low-overhead hardware-level isolation.

[0031] Root cell: The main running domain in the Jailhouse, typically running a Linux system, responsible for network and peripheral management, and also handling the configuration and distribution of LLC allocation policies.

[0032] Inmate cell: A slave runtime domain in Jailhouse that can run real-time operating systems such as RTOS for performing latency-sensitive real-time tasks.

[0033] RTOS: Real-Time Operating System. It has strict requirements on task execution latency and determinism and is often used in real-time business scenarios of mixed mission-critical systems.

[0034] Way group: The hardware-level partitioning unit of LLC is the smallest hardware granularity of cache allocation in this invention, and can be allocated to different schemes in groups.

[0035] CLUSTERPARTCR_EL1: A hardware register in the ARM architecture used to configure LLC partition mapping. This invention enables the mapping from way group to scheme by writing to this register.

[0036] CLUSTERTHREADSID_EL1: A hardware register in the ARM architecture used to bind the CPU core to the scheme ID, completing the static binding of the core and cache resources.

[0037] EL2 / EL3: Exception levels for ARM architecture. EL2 is the exception level for the virtualization layer, and EL3 is the exception level for the trusted firmware / security monitoring layer.

[0038] SMC: Secure Monitor Call, an interface used for interaction between EL3 trusted firmware in the ARM architecture. Existing technologies use this interface to distribute cache configurations.

[0039] SoC: System on Chip, an embedded core chip that integrates hardware resources such as CPU, cache, and peripherals, and is the application carrier of this invention.

[0040] cache_partitioner: This is a new module added to the Jailhouse hypervisor in this invention. It is responsible for parsing cache configuration, converting and issuing register instructions to complete LLC allocation.

[0041] PARTCR: This is a bitmask in the configuration file of this invention used to define the mapping from way group to scheme, and is a core configuration item for LLC allocation strategy.

[0042] THREADSID: A configuration item in the configuration file of this invention used to define the binding relationship between CPU cores and scheme IDs, realizing a static correspondence between cores and cache resources.

[0043] The technical solution of the present invention will now be described in further detail with reference to the accompanying drawings.

[0044] like Figure 1 As shown, the LLC allocation method based on Jailhouse in this embodiment is applied to an ARM platform that supports DSU, and the method includes: S101. Formulate LLC allocation strategy: Determine the mapping relationship between each way group and each scheme of LLC, and clarify the set of way groups that each scheme is allowed to access; Based on the caching requirements of each cell and the CPU cores used by each cell, bind a scheme ID to each CPU core to ensure that the set of way groups of LLCs that can be accessed by the CPU cores used by different cells do not overlap. S102. Fill in the configuration file: Write the LLC allocation strategy as allocation configuration information and write the allocation configuration information into the Jailhouse root cell configuration file; S103, LLC allocation strategy issuance: During the Jailhouse enable phase, the root cell configuration file is parsed, the allocation configuration information is extracted, and the CLUSTERPARTCR_EL1 register and CLUSTERTHREADSID_EL1 register are configured according to the allocation configuration information.

[0045] This embodiment's Jailhouse-based LLC allocation method, by configuring the CLUSTERPARTCR_EL1 and CLUSTERTHREADSID_EL1 registers, enables the LLC allocation strategy to take effect directly at the hardware level. This ensures that the CPU cores used by different cells are physically restricted to cache access within their respective allocated way group sets, fundamentally eliminating LLC cache conflicts between different cells, effectively eliminating access latency jitter, ensuring system determinism and security, and meeting the security, real-time, and predictability requirements of hybrid mission-critical systems. This embodiment integrates the LLC allocation strategy as allocation configuration information into the Jailhouse root cell configuration file and performs this configuration during the Jailhouse startup phase. The cell configuration file is parsed, enabling Jailhouse to perceive and manage LLC configurations. This perfectly matches its core architecture of static partitioning and hardware-level isolation, without compromising its static trust boundary. This avoids the complexity and trust chain disruption issues introduced by relying on external components (such as EL3 firmware). Furthermore, this embodiment does not constrain the allocation of physical pages, but only divides the LLC's waygroups. This helps ensure that the number of available physical pages for each cell matches its pre-allocated value, improving memory utilization. At the same time, as the number of cells increases, this embodiment can flexibly adjust the allocation combination of waygroups, avoiding the dilution of available resources and providing good scalability.

[0046] Furthermore, in this embodiment, step S101, determining the mapping relationship between each way group of the LLC and each scheme, and clarifying the specific steps of the set of way groups that each scheme is allowed to access, includes: Based on the total LLC capacity of the SoC, the number and size of way groups, and the cache requirements of each cell, the LLC allocation ratio for each cell is determined, and the corresponding way group sets are assigned to different schemes according to this allocation ratio. The specific steps for binding a corresponding scheme ID to each CPU core, based on the cache requirements of each cell and the CPU cores used by each cell, include: binding all CPU cores belonging to the same cell to the same scheme ID; for CPU cores belonging to different cells, their respective bound scheme IDs are different, and each scheme ID corresponds to only one CPU core in one cell. Specifically, the higher the cache requirements of a cell, the more way groups the CPU cores used by that cell can access. The fact that CPU cores belonging to different cells have different bound scheme IDs ensures that data from tasks running on any cell cannot occupy or evict the cache space of another cell, physically preventing cross-domain cache interference.

[0047] Furthermore, in this embodiment, the allocation configuration information includes: the set of way groups that each scheme is allowed to access, represented in the form of a bitmap mask, and the scheme ID information bound to each CPU core.

[0048] Further, in this embodiment, in step S102, the allocation configuration information is written into the extended cache_partition field of the root cell configuration file. The cache_partition field is a dedicated field used to store LLC allocation strategies. It is conceivable that the name of the cache_partition field could be different in other embodiments. The Jailhouse hypervisor includes a cache partitioner module (cache_partitioner module), which executes step S103. The cache partitioner module parses the cache_partition field of the root cell configuration file, extracts the bitmap mask to configure the CLUSTERPARTCR_EL1 register, and extracts the scheme ID information bound to each CPU core to configure the CLUSTERTHREADSID_EL1 register. This achieves the goal of adding only a cache_partitioner module at the Jailhouse hypervisor layer, using EL2 to directly write to the register, without requiring modification to the trusted firmware.

[0049] To intuitively illustrate the specific implementation process of this embodiment, the following detailed explanation of the method's execution steps is provided through a complete example, using a real-world application scenario of the NXP i.MX95 embedded multi-core platform: This example is based on a mature commercial ARMv8-A architecture embedded platform, and the hardware and virtualization environment configuration is as follows: Hardware platform: NXP i.MX95 (ARMv8 AArch64 architecture, natively supports DSU cache partitioning technology) CPU resources: 6 physical cores, numbered CPU0 to CPU5 LLC last-level cache: total capacity 512KB, hardware-divided into 4 independent way groups (group0 ~group3), each group capacity 128KB. Virtualization Management: Jailhouse Cell zoning planning: Root Cell: Runs the Linux system and is responsible for general tasks such as network management and peripheral drivers. It uses CPU0 to CPU3 (4 cores). Inmate Cell: Runs an RTOS (Real-Time Operating System) responsible for latency-sensitive real-time tasks, consuming 4-5 CPU cores. The specific implementation process is as follows: S101. Formulate LLC allocation strategy: Based on the platform's hardware resources and the characteristics of dual-cell services, non-overlapping and physically isolated cache allocation rules were formulated: Determine the cache allocation ratio: Linux general business uses 3 / 4 LLC, and RTOS real-time business uses 1 / 4 LLC; Determine the mapping relationship between each way group and each scheme: Linux binds scheme0, granting access to three way groups: group0, group1, and group2. The RTOS binds to scheme1 and authorizes access to a way group in group3; CPU cores are bound to scheme IDs. CPU cores within the same cell are bound to the same scheme ID, while CPU cores in different cells are bound to different scheme IDs. scheme id: CPU0~CPU3→scheme0 (number 0x0); scheme id: CPU4~CPU5→scheme1 (number 0x1); This rule ensures that the dual-cell cache spaces are physically isolated, with no cross-access and no cache contention.

[0050] S102. Fill in the configuration file: Convert the LLC allocation strategy into configuration parameters that Jailhouse can recognize. The core is to calculate the PARTCR bitmap mask (used to configure the CLUSTERPARTCR_EL1 register) and configure the mapping relationship between CPU cores and scheme IDs.

[0051] PARTCR bitmap mapping rules: Register bit index calculation formula: bit_index = scheme_id * N_group + group_index Where N_group=4 (total number of way groups), scheme_id takes values ​​from 0 to 7, and group_index takes values ​​from 0 to 3.

[0052] Bitmap mask calculation: scheme0 → group0, group1, group2 group0 → 1<<(0*4 + 0) = 1<<0 = 0x01 group1 → 1<<(0*4 + 1) = 1<<1 = 0x02 group2 → 1<<(0*4 + 2) = 1<<2 = 0x04 Merge mask: 0x01 | 0x02 | 0x04 = 0x07 (binary 0000_0111) scheme1 → group3 Group3 → 1<<(1*4 + 3) = 1<<7 = 0x80 (binary 1000_0000) Final total PARTCR bitmap mask: 0x07 | 0x80 = 0x87 In the Jailhouse root cell configuration file, use the newly added dedicated `cache_partition` field to write the following allocation configuration information: cache_partition = { .PARTCR = 0x87, / / way group→scheme mapping bitmap .THREADSID = { / / Scheme ID of CPU core { 0x0, / / CPU0 → Bind scheme0 }, { 0x0, / / CPU1 → Bind scheme0 }, { 0x0, / / CPU2 → Bind scheme0 }, { 0x0, / / CPU3 → Bind scheme0 }, { 0x1, / / CPU4 → Bind scheme1 }, { 0x1, / / CPU5 → Bind scheme1 }, }, }; Among them, PARTCR = 0x87: the CLUSTERPARTCR_EL1 register configuration value, defines the cache way groups accessible to each scheme; .THREADSID array: specifies the scheme ID bound to each core in CPU core order, realizing core-level cache access control. This parameterization of bitmap and bit numbering rules can adapt to different numbers of way-groups, multiple scheme configurations, and static binding of arbitrary CPU subsets, and is easily scalable to SoCs with multiple clusters or larger core counts.

[0053] S103, LLC allocation strategy distribution: The cache_partitioner module is responsible for parsing the configuration and distributing registers. Its core pseudocode is as follows: / * * Cache partition initialization function: Automatically called during the Jailhouse enable phase. * Input parameters: Overall jailhouse configuration structure (including cache_partition configuration) * Return value: 0 - initialization successful, negative - configuration error / int cache_partitioner_init(struct jailhouse_config *cfg) { / / 1. Verification: If the cache partitioning function is not enabled, exit directly without performing any subsequent operations. if (!cfg->cache_partition.present) return 0; / / 2. Read configuration: Obtain the PARTCR bitmap mask from the root cell configuration file uint32_t partcr_val = cfg->cache_partition.partcr; / / 3. Define an array: to store the scheme ID bound to each CPU core uint8_t threadsid[NUM_CPUS]; / / 4. Traverse all CPU cores, read and verify the scheme ID configuration. for (cpu = 0; cpu <NUM_CPUS; ++cpu) { / / Read the scheme ID bound to the current CPU core from the configuration. threadsid[cpu] = cfg->cache_partition.threadsid[cpu]; / / Validity check: If the scheme id exceeds the maximum value, return an error. if (threadsid[cpu]>MAX_SCHEME_ID) return -EINVAL; } / / 5. Hardware configuration: Write to CLUSTERPARTCR_EL1 register / / Function: Writes the mapping relationship between scheme and way group to the hardware, and applies the cache partitioning rules. write_clusterpartcr_el1(partcr_val); / / 6. Hardware configuration: Write to the CLUSTERTHREADSID_EL1 register one core at a time / / Function: To bind a scheme ID to each CPU core, thereby enabling core-level cache access control. for (cpu = 0; cpu <NUM_CPUS; ++cpu) write_clusterthreadsid_el1_for_cpu(cpu, threadsid[cpu]); return 0; } After completing the above steps, create and run the inmate cell. Once the inmate cell starts, Linux and RTOS run on their respective allocated CPU cores and use isolated LLCs according to the LLC allocation policy. This avoids cache contention caused by Linux leading to the replacement of RTOS data, reduces access latency jitter, improves the determinism and real-time performance of RTOS, and minimizes WECT.

[0054] Furthermore, this embodiment also provides a Jailhouse-based LLC allocation system, including an interconnected microprocessor and a memory, wherein the microprocessor is programmed or configured to execute a Jailhouse-based LLC allocation method.

[0055] In addition, this embodiment also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute a Jailhouse-based LLC allocation method by a processor.

[0056] In addition, this embodiment also provides a computer program product, including a computer program or instructions that are programmed or configured to execute a Jailhouse-based LLC allocation method via a processor.

[0057] Those skilled in the art will understand that the technical solutions provided by the embodiments of this application may be in the form of a method, system, or computer program product. Therefore, this application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application may take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create an implementation for the process. Figure 1 One or more processes and / or boxes Figure 1The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0058] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A Jailhouse-based LLC allocation method, applied to an ARM platform supporting DSU, characterized in that, The method includes: S101. Formulate LLC allocation strategy: Determine the mapping relationship between each way group and each scheme of LLC, and clarify the set of way groups that each scheme is allowed to access; Based on the caching requirements of each cell and the CPU cores used by each cell, bind a scheme ID to each CPU core to ensure that the set of way groups of LLCs that can be accessed by the CPU cores used by different cells do not overlap. S102. Fill in the configuration file: Write the LLC allocation strategy as allocation configuration information and write the allocation configuration information into the Jailhouse root cell configuration file; S103, LLC allocation strategy issuance: During the Jailhouse activation phase, the root cell configuration file is parsed, the allocation configuration information is extracted, and the CLUSTERPARTCR_EL1 register and CLUSTERTHREADSID_EL1 register are configured according to the allocation configuration information.

2. The LLC allocation method based on Jailhouse according to claim 1, characterized in that, In step S101, the specific steps for determining the mapping relationship between each way group and each scheme of the LLC, and clarifying the set of way groups that each scheme is allowed to access, include: Based on the total LLC capacity of the SoC, the number and size of way groups, and the cache requirements of each cell, determine the LLC allocation ratio for each cell, and then allocate the corresponding way group set to different schemes according to the allocation ratio.

3. The LLC allocation method based on Jailhouse according to claim 1, characterized in that, In step S101, based on the caching requirements of each cell and the CPU cores used by each cell, the specific steps for binding a corresponding scheme ID to each CPU core include: binding all CPU cores belonging to the same cell to the same scheme ID; for CPU cores belonging to different cells, their respective bound scheme IDs are different, and each scheme ID corresponds to only one CPU core of a cell.

4. The LLC allocation method based on Jailhouse according to claim 1, characterized in that, The allocation configuration information includes: the set of way groups that each scheme is allowed to access, represented in bitmap mask form, and the scheme ID information bound to each CPU core.

5. The LLC allocation method based on Jailhouse according to claim 4, characterized in that, In step S102, the allocation configuration information is written into the cache_partition field of the root cell configuration file, where the cache_partition field is a dedicated field for storing LLC allocation strategies.

6. The LLC allocation method based on Jailhouse according to claim 5, characterized in that, In step S103, the cache_partition field of the root cell configuration file is parsed, the bitmap mask is extracted to configure the CLUSTERPARTCR_EL1 register, and the scheme id information bound to each CPU core is extracted to configure the CLUSTERTHREADSID_EL1 register.

7. The LLC allocation method based on Jailhouse according to claim 1, characterized in that, The Jailhouse hypervisor includes a cache partitioner module, which is used to execute step S103.

8. A Jailhouse-based LLC allocation system, comprising interconnected microprocessors and memory, characterized in that, The microprocessor is programmed or configured to execute the Jailhouse-based LLC allocation method as described in any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the Jailhouse-based LLC allocation method as described in any one of claims 1 to 7 via a processor.

10. A computer program product, comprising a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the Jailhouse-based LLC allocation method as described in any one of claims 1 to 7 via a processor.

Images