Re: [PATCH 16/36] xen/color alloc: implement color_from_page for ARM64

[Julien Grall <julien@xxxxxxx>]

Hi Marco,

On 11/03/2022 17:39, Marco Solieri wrote:
> On Fri, Mar 04, 2022 at 08:54:35PM +0000, Julien Grall wrote:
> > On 04/03/2022 17:46, Marco Solieri wrote:
> > > The colored allocator should not make any assumptions on how a color
> > > is defined, since the definition may change depending on the
> > > architecture.
> > IIUC, you are saying that the mapping between a physical address to a
> > way is the same on every Armv8 processor.
> >
> > Can you provide a reference from the Arm Arm which confirm this
> > statement?
> We are actually stating quite the opposite.  Generally speaking, the Arm
> ARM leaves as IMPLEMENTATION DEFINED many details that are needed to
> determine how colouring should be defined, most notably:
> - the physical vs virtual indexing, which determines whether colouring
>    is possible;
> - the cache line length and the degree of associativity, which determine
>    the way size, which in turn, together with the page size selected by
>    the OS/hypervisor, allows to compute the number of available colours;
> - the number of levels of shared caches, which determines the number of
>    different colour sets.
>
> For the sake of simplicity, we wanted to decouple the notion of colour
> from the many hardware features that enable/suggest one of the
> (sometimes many) instantiations.
>
> All these details are usually reported in the processor TRM.  E.g., in
> the A53 TRM [DDI 0500J] we read (Sec. 7.1):
>
> | Optional tightly-coupled L2 cache that includes:
> | — Configurable L2 cache size of 128KB, 256KB, 512KB, 1MB and 2MB.
> | — Fixed line length of 64 bytes.
> | — Physically indexed and tagged cache.
> | — 16-way set-associative cache structure.
Thanks for the details. They are all about the variables of an equation. 
What I am looking for is how the equation calculate_addr_col_mask() in 
patch #6 was defined.
Cheers,

--
Julien Grall