linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] irqchip/gicv3-its: Add missing changes to support 52bit physical address
Date: Sat, 07 Oct 2017 10:58:54 +0100	[thread overview]
Message-ID: <867ew7mg81.fsf@arm.com> (raw)
In-Reply-To: <1507353204-28808-1-git-send-email-shankerd@codeaurora.org> (Shanker Donthineni's message of "Sat, 7 Oct 2017 00:13:24 -0500")

On Sat, Oct 07 2017 at 12:13:24 am BST, Shanker Donthineni <shankerd@codeaurora.org> wrote:
> The current ITS driver works fine as long as normal memory and GICR
> regions are located within the lower 48bit (>=0 && <2^48) physical
> address space. Some of the registers GICR_PEND/PROP, GICR_VPEND/VPROP
> and GITS_CBASER are handled properly but not all when configuring
> the hardware with 52bit physical address.
>
> This patch does the following changes to support 52bit PA.
>   -Handle 52bit PA in GITS_BASERn.
>   -Fix ITT_addr width to 52bits, bits[51:8].
>   -Fix RDbase width to 52bits, bits[51:16].
>   -Fix VPT_addr width to 52bits, bits[51:16].
>
> Definition of the GITS_BASERn register when ITS PageSize is 64KB:
>  -Bits[47:16] of the register provide bits[47:16] of the table PA.
>  -Bits[15:12] of the register provide bits[51:48] of the table PA.
>  -Bits[15:00] of the base physical address are 0.
>
> Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
> ---
>  drivers/irqchip/irq-gic-v3-its.c   | 24 +++++++++++++++++++-----
>  include/linux/irqchip/arm-gic-v3.h |  3 +++
>  2 files changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index e8d8934..e52c0da 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -308,7 +308,7 @@ static void its_encode_size(struct its_cmd_block *cmd, u8 size)
>  
>  static void its_encode_itt(struct its_cmd_block *cmd, u64 itt_addr)
>  {
> -	its_mask_encode(&cmd->raw_cmd[2], itt_addr >> 8, 50, 8);
> +	its_mask_encode(&cmd->raw_cmd[2], itt_addr >> 8, 51, 8);
>  }
>  
>  static void its_encode_valid(struct its_cmd_block *cmd, int valid)
> @@ -318,7 +318,7 @@ static void its_encode_valid(struct its_cmd_block *cmd, int valid)
>  
>  static void its_encode_target(struct its_cmd_block *cmd, u64 target_addr)
>  {
> -	its_mask_encode(&cmd->raw_cmd[2], target_addr >> 16, 50, 16);
> +	its_mask_encode(&cmd->raw_cmd[2], target_addr >> 16, 51, 16);
>  }
>  
>  static void its_encode_collection(struct its_cmd_block *cmd, u16 col)
> @@ -358,7 +358,7 @@ static void its_encode_its_list(struct its_cmd_block *cmd, u16 its_list)
>  
>  static void its_encode_vpt_addr(struct its_cmd_block *cmd, u64 vpt_pa)
>  {
> -	its_mask_encode(&cmd->raw_cmd[3], vpt_pa >> 16, 50, 16);
> +	its_mask_encode(&cmd->raw_cmd[3], vpt_pa >> 16, 51, 16);
>  }
>  
>  static void its_encode_vpt_size(struct its_cmd_block *cmd, u8 vpt_size)
> @@ -1478,9 +1478,9 @@ static int its_setup_baser(struct its_node *its, struct its_baser *baser,
>  	u64 val = its_read_baser(its, baser);
>  	u64 esz = GITS_BASER_ENTRY_SIZE(val);
>  	u64 type = GITS_BASER_TYPE(val);
> +	u64 baser_phys, tmp;
>  	u32 alloc_pages;
>  	void *base;
> -	u64 tmp;
>  
>  retry_alloc_baser:
>  	alloc_pages = (PAGE_ORDER_TO_SIZE(order) / psz);
> @@ -1496,8 +1496,22 @@ static int its_setup_baser(struct its_node *its, struct its_baser *baser,
>  	if (!base)
>  		return -ENOMEM;
>  
> +	baser_phys = virt_to_phys(base);
> +
> +	/* Check if the physical address of the memory is above 48bits */
> +	if (baser_phys & (~GITS_BASER_PHYS_MASK)) {
> +		/* 52bit PA is supported only when PageSize=64K */
> +		if (psz != SZ_64K) {
> +			free_pages((unsigned long)base, order);
> +			return -EFAULT;
> +		}
> +
> +		/* Convert 52bit PA to 48bit field */
> +		baser_phys = GITS_BASER_64K_PHYS(baser_phys);
> +	}

I'm not sure this is completely right. What guarantees that the memory
you get is 64kB aligned? Your initial masking will do the wrong thing on
a system with 16kB pages, and everything will break from that point on,
as you're confusing the ITS page size with the CPU page size.

This probably wants to be predicated with a 64kB CPU page size (which is
the only valid configuration for 52bit PA anyway).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.

  reply	other threads:[~2017-10-07  9:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-07  5:13 [PATCH] irqchip/gicv3-its: Add missing changes to support 52bit physical address Shanker Donthineni
2017-10-07  9:58 ` Marc Zyngier [this message]
2017-10-07 12:59   ` Shanker Donthineni
2017-10-07 18:43     ` Shanker Donthineni

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=867ew7mg81.fsf@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).