Re: [PATCH v5 00/13] Arm cache coloring

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 3 Jan 2024, Michal Orzel wrote:
> 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.

Also I tried this patch series on the "staging" branch and Xen failed to
boot, no messages at all from Xen so it must be an early boot failure. I
am passing this command line options to Xen and running it on QEMU:

dom0_mem=1024M dom0_max_vcpus=1 xen-llc-colors=0 dom0-llc-colors=1-5 
llc-way-size=65535 llc-coloring=true