| Message ID | 20220304174701.1453977-17-marco.solieri@minervasys.tech (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Arm cache coloring | expand |
Hi, On 04/03/2022 17:46, Marco Solieri wrote: > From: Luca Miccio <lucmiccio@gmail.com> > > 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? Cheers,
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. A simplified version of this configuration is implemented in PATCH 06/36, where the fallback automatic configuration assumes that colouring targets the LLC, and that this is the only shared cache level. I hope that this clarify some points. Cheers.
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,
diff --git a/xen/arch/arm/coloring.c b/xen/arch/arm/coloring.c index 8061c3824f..4748d717d6 100644 --- a/xen/arch/arm/coloring.c +++ b/xen/arch/arm/coloring.c @@ -196,6 +196,19 @@ bool check_domain_colors(struct domain *d) return !ret; } +/* + * Compute color id from the page @param pg. + * Page size determines the lowest available bit, while add_col_mask is used to + * select the rest. + * + * @param pg Page address + * @return unsigned long Color id + */ +unsigned long color_from_page(struct page_info *pg) +{ + return ((addr_col_mask & page_to_maddr(pg)) >> PAGE_SHIFT); +} + bool __init coloring_init(void) { int i; diff --git a/xen/arch/arm/include/asm/coloring.h b/xen/arch/arm/include/asm/coloring.h index 8609e17e80..318e2a4521 100644 --- a/xen/arch/arm/include/asm/coloring.h +++ b/xen/arch/arm/include/asm/coloring.h @@ -42,6 +42,13 @@ bool check_domain_colors(struct domain *d); uint32_t *setup_default_colors(uint32_t *col_num); void coloring_dump_info(struct domain *d); + +/* + * Compute the color of the given page address. + * This function should change depending on the cache architecture + * specifications. + */ +unsigned long color_from_page(struct page_info *pg); #else /* !CONFIG_COLORING */ static inline bool __init coloring_init(void) {