Hi, On 02/01/2024 10:51, Carlo Nonato wrote: > > > Shared caches in multi-core CPU architectures represent a problem for > predictability of memory access latency. This jeopardizes applicability > of many Arm platform in real-time critical and mixed-criticality > scenarios. We introduce support for cache partitioning with page > coloring, a transparent software technique that enables isolation > between domains and Xen, and thus avoids cache interference. > > When creating a domain, a simple syntax (e.g. `0-3` or `4-11`) allows > the user to define assignments of cache partitions ids, called colors, > where assigning different colors guarantees no mutual eviction on cache > will ever happen. This instructs the Xen memory allocator to provide > the i-th color assignee only with pages that maps to color i, i.e. that > are indexed in the i-th cache partition. > > The proposed implementation supports the dom0less feature. > The proposed implementation doesn't support the static-mem feature. > The solution has been tested in several scenarios, including Xilinx Zynq > MPSoCs. > > In this patch series there are two major unacceptable workarounds for which > I want to ask you for comments: > - #3: allocate_memory() has been moved in dom0less_build.c, so I just copied > it back to make it compile. I would move it to domain_build.c and add a prototype in domain_build.h. You could guard it together with allocate_bank_memory() for DOM0LESS || LLC or just remove the guards (in former case, you would need to protect your call with #ifdef in construct_dom0()).
> - #13: consider_modules() has been moved to arm32 only. Again I just copied > it. I would move it to setup.c and add a prototype in setup.h. As for the guards, if we want them (personally I don't see the need), you would need LLC || (ARM_32 && MMU). BTW. Patchew reports some build issues in your series: https://gitlab.com/xen-project/patchew/xen/-/pipelines/1124313980 Make sure to build test your series on different arches. You can ask on IRC to become a member on gitlab so that you can trigger the pipeline by pushing the changes to your fork on people/<you>/xen. ~Michal
