[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen/arm: scan CLIDR Ctype fields upwards when probing LLC


  • To: "Orzel, Michal" <michal.orzel@xxxxxxx>
  • From: Mykola Kvach <xakep.amatop@xxxxxxxxx>
  • Date: Fri, 22 May 2026 13:13:47 +0300
  • Arc-authentication-results: i=1; mx.google.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=JUX6vHTa7p0Sfwz+CeidZwv32/WawPrRTHCpIPs0Gdc=; fh=zL8KVAj6rSaYbk/102rEWeOa69wm5cw+i9nXMzeM8z8=; b=VcxvFykSeKMh428DFLWUPtDRfjZLT/VIYvSLXdWHl0bDocDI6WcAMOIHuEZn1ckF1d NWzJBJroYQfAZdS8Un+/m/mQR3lZLb7tgKZmcW9USR11uAtr3a/ZsLKbPn10wS0He0uN IOvHsTwjqJZ8UPp4KbXgBvDVXIfNyHF5GCDuhQIJBdfq2SiRgEr4G7HVmTjUs8GVDjqg 7mHvhV/tb72ABjDBC6BxnGoie0nUvHTcO5JB3bfGrwkSSPSJibLYQ3uXONX/Pm0Cki2i k5TnR3yAL/gAAZsUa9ljLxIbXUXBLUlAbFKLEXOEZ4zwnoBicePx9EwDvcvgUCX+m0st j1Jw==; darn=lists.xenproject.org
  • Arc-seal: i=1; a=rsa-sha256; t=1779444839; cv=none; d=google.com; s=arc-20240605; b=OUUAqPPwaFFD9BYbhTUT1OEw6GJXMo++kT9TFhr8Ubm48hiNvY0fdTkUtZEtS2Flff +1BsSvS+q5b0Cw0dhekgxOB/Ib5bilfAzszVkKmxfwiUFlSSF7kiLmE014P/PDA1QJZ6 aiC0cVsWMZ05PuWEhLwPyOhG/8YWTXaiYsYUdB8EteMw+qWOm3VzDP37vOurQKNwuy45 QUaXlLWxUS6rtbR4SyP8GfikV/Z2Dis+wc5gWPpsBVJtnzzjIM2C5ZdSjB6WLLznTlK/ J+HVHqNOwJihksa2YOxJFqbQqJlkwXLozrpOEYzog/AN+zEfQ6s+4rRwExB2QMUEch+E q1NA==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Mykola Kvach <mykola_kvach@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Fri, 22 May 2026 10:14:15 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Michal,

Thank you for the feedback.

On Fri, May 22, 2026 at 9:41 AM Orzel, Michal <michal.orzel@xxxxxxx> wrote:
>
>
>
> On 04-May-26 11:19, Mykola Kvach wrote:
> > From: Mykola Kvach <mykola_kvach@xxxxxxxx>
> >
> > get_llc_way_size() currently scans CLIDR_EL1 Ctype fields from the
> > highest level downwards and stops at the first unified cache it finds.
> >
> > However, CLIDR_EL1 describes the cache hierarchy from Ctype1 upwards.
> > Arm ARM DDI 0487J.a, D19.2.27 says that once software has seen a
> > Ctype value of 0b000 while reading from Ctype1 upwards, no caches
> > manageable by the architected set/way maintenance instructions exist at
> > further-out levels, and the higher Ctype fields must be ignored.
> >
> > The current reverse scan can therefore select a unified cache level from
> > a Ctype field above the first no-cache level. Such a field is not part of
> > the architecturally described CLIDR/CCSIDR cache hierarchy and should not
> > be used for selecting the CCSIDR level.
> >
> > Scan Ctype fields from L1 upwards, stop at the first no-cache level, and
> > keep the outermost unified cache observed before that point.
> >
> > This preserves the result for regular cache hierarchies, while avoiding
> > selection of an architecturally ignored Ctype field.
> >
> > Fixes: f4985fce6f0b ("xen/arm: add initial support for LLC coloring on 
> > arm64")
> > Signed-off-by: Mykola Kvach <mykola_kvach@xxxxxxxx>
> > ---
> > This patch follows the xen-devel discussion:
> > https://lists.xenproject.org/archives/html/xen-devel/2026-01/msg00345.html
> >
> > In that thread, Michal noted that the reverse scan was a simplification
> > rather than an intentional requirement, and that changing the
> > implementation would be fine.
> >
> > Testing performed:
> > - standalone synthetic CLIDR tests covered both regular and pathological
> >   Ctype sequences and showed that the forward scan ignores unified cache
> >   levels above the first Ctype == 0b000 while the reverse scan can pick
> >   them
> > - Renesas H3ULCB booted with llc-coloring=on
> > ---
> >  xen/arch/arm/llc-coloring.c | 22 +++++++++++++++++-----
> >  1 file changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c
> > index 6f78817c57..3783f4c824 100644
> > --- a/xen/arch/arm/llc-coloring.c
> > +++ b/xen/arch/arm/llc-coloring.c
> > @@ -22,21 +22,33 @@ unsigned int __init get_llc_way_size(void)
> >      register_t id_aa64mmfr2_el1 = READ_SYSREG(ID_AA64MMFR2_EL1);
> >      uint32_t ccsidr_numsets_shift = CCSIDR_NUMSETS_SHIFT;
> >      uint32_t ccsidr_numsets_mask = CCSIDR_NUMSETS_MASK;
> > -    unsigned int n, line_size, num_sets;
> > -
> > -    for ( n = CLIDR_CTYPEn_LEVELS; n != 0; n-- )
> > +    unsigned int n, line_size, num_sets, llc_level = 0;
> > +
> > +    /*
> > +     * CLIDR_EL1 Ctype fields are interpreted from Ctype1 upwards. Once a
> > +     * no-cache level is seen, higher Ctype fields are architecturally 
> > ignored
> > +     * for the CLIDR/CCSIDR set/way manageable cache hierarchy.
> > +     *
> > +     * Keep the outermost unified cache before that point.
> > +     */
> > +    for ( n = 1; n <= CLIDR_CTYPEn_LEVELS; n++ )
> >      {
> >          uint8_t ctype_n = (clidr_el1 >> CLIDR_CTYPEn_SHIFT(n)) &
> >                             CLIDR_CTYPEn_MASK;
> >
> > +        if ( ctype_n == 0b000 )
> > +            break;
> > +
> >          /* Unified cache (see Arm ARM DDI 0487J.a D19.2.27) */
> >          if ( ctype_n == 0b100 )
> > -            break;
> > +            llc_level = n;
> >      }
> >
> > -    if ( n == 0 )
> > +    if ( !llc_level )
> >          return 0;
> >
> > +    n = llc_level;
> After a loop, n does not carry any meaning, so I find this assignment a bit 
> odd
> and confusing to read. Just use llc_level below. With that:

Ack.

Best regards,
Mykola



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.