All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: wangwudi <wangwudi@hisilicon.com>
Cc: <linux-kernel@vger.kernel.org>, <liaochang1@huawei.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2] irqchip: gic-v3: Extend collection table
Date: Thu, 08 Jun 2023 09:10:24 +0100	[thread overview]
Message-ID: <87cz26nzm7.wl-maz@kernel.org> (raw)
In-Reply-To: <1686131113-3611-1-git-send-email-wangwudi@hisilicon.com>

On Wed, 07 Jun 2023 10:45:13 +0100,
wangwudi <wangwudi@hisilicon.com> wrote:
> 
> Only single level table is supported to the collection table, and only
> one page is allocated.
> 
> Extend collection table to support more CPUs:
> 1. Recalculate the page number of collection table based on the number of
> CPUs.
> 2. Add 2 level tables to collection table.
> 3. Add GITS_TYPER_CIDBITS macros.
> 
> It is noticed in an internal simulation research:
> - the page_size of collection table is 4 KB
> - the entry_size of collection table is	 16 Byte
> - with 512 CPUs
> 
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Marc Zyngier <maz@kernel.org>
> Signed-off-by: wangwudi <wangwudi@hisilicon.com>
> ---
> 
> ChangeLog:
> v1-->v2:
> 	1. Support 2 level table
> 	2. Rewrite the commit log
> 
>  drivers/irqchip/irq-gic-v3-its.c   | 62 ++++++++++++++++++++++++++++++--------
>  include/linux/irqchip/arm-gic-v3.h |  3 ++
>  2 files changed, 53 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 0ec2b1e1df75..573ef26ad449 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -126,6 +126,7 @@ struct its_node {
>  #define is_v4(its)		(!!((its)->typer & GITS_TYPER_VLPIS))
>  #define is_v4_1(its)		(!!((its)->typer & GITS_TYPER_VMAPP))
>  #define device_ids(its)		(FIELD_GET(GITS_TYPER_DEVBITS, (its)->typer) + 1)
> +#define collection_ids(its)	(FIELD_GET(GITS_TYPER_CIDBITS, (its)->typer) + 1)
>  
>  #define ITS_ITT_ALIGN		SZ_256
>  
> @@ -2626,6 +2627,10 @@ static int its_alloc_tables(struct its_node *its)
>  			indirect = its_parse_indirect_baser(its, baser, &order,
>  							    ITS_MAX_VPEID_BITS);
>  			break;
> +		case GITS_BASER_TYPE_COLLECTION:
> +			indirect = its_parse_indirect_baser(its, baser, &order,
> +							    order_base_2(num_possible_cpus()));
> +			break;

Nice try, but no. See below.

>  		}
>  
>  		err = its_setup_baser(its, baser, cache, shr, order, indirect);
> @@ -3230,18 +3235,6 @@ static void its_cpu_init_collection(struct its_node *its)
>  	its_send_invall(its, &its->collections[cpu]);
>  }
>  
> -static void its_cpu_init_collections(void)
> -{
> -	struct its_node *its;
> -
> -	raw_spin_lock(&its_lock);
> -
> -	list_for_each_entry(its, &its_nodes, entry)
> -		its_cpu_init_collection(its);
> -
> -	raw_spin_unlock(&its_lock);
> -}
> -
>  static struct its_device *its_find_device(struct its_node *its, u32 dev_id)
>  {
>  	struct its_device *its_dev = NULL, *tmp;
> @@ -3316,6 +3309,51 @@ static bool its_alloc_table_entry(struct its_node *its,
>  	return true;
>  }
>  
> +static bool its_alloc_collection_table(struct its_node *its, struct its_baser *baser)
> +{
> +	int cpu = smp_processor_id();
> +	int cpu_ids = 16;
> +
> +	if (its->typer & GITS_TYPER_CIL)
> +		cpu_ids = collection_ids(its);
> +
> +	if (!(ilog2(cpu) < cpu_ids)) {
> +		pr_warn("ITS: CPU%d out of Collection ID range for %dbits", cpu, cpu_ids);
> +		return false;
> +	}
> +
> +	if (!its_alloc_table_entry(its, baser, cpu)) {
> +		pr_warn("ITS: CPU%d failed to allocate collection l2 table", cpu);
> +		return false;
> +	}
> +
> +	return true;
> +}
> +
> +static bool its_cpu_init_collections(void)
> +{
> +	struct its_node *its;
> +	struct its_baser *baser;
> +
> +	raw_spin_lock(&its_lock);
> +
> +	list_for_each_entry(its, &its_nodes, entry) {
> +		baser = its_get_baser(its, GITS_BASER_TYPE_COLLECTION);
> +		if (!baser) {
> +			raw_spin_unlock(&its_lock);
> +			return false;
> +		}

This looks wrong. ITSs that have a non-zero HCC field may not need
memory to back their collections at all, such as GIC500. There may not
even be a BASERn register holding the memory.

So this patch more or less *guarantees* to break most implementation
that are more than 5 year old.

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2023-06-08  8:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-07  9:45 [PATCH v2] irqchip: gic-v3: Extend collection table wangwudi
2023-06-08  8:10 ` Marc Zyngier [this message]
     [not found]   ` <82ea3d910d104fbb8df9b27585085895@hisilicon.com>
2023-06-09 10:02     ` wangwudi
2023-06-09 13:10       ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87cz26nzm7.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=liaochang1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=wangwudi@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.