mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Hector Martin <marcan@marcan.st>, Sven Peter <sven@svenpeter.dev>,
	Will Deacon <will@kernel.org>
Cc: Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Joerg Roedel <joro@8bytes.org>,
	linux-arm-kernel@lists.infradead.org,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/io-pgtable-arm: Fix table descriptor paddr formatting
Date: Wed, 17 Nov 2021 17:46:33 +0000	[thread overview]
Message-ID: <a2b45243-7e0a-a2ac-4e14-5256a3e7abb4@arm.com> (raw)
In-Reply-To: <20211117171213.243584-1-marcan@marcan.st>

On 2021-11-17 17:12, Hector Martin wrote:
> Table descriptors were being installed without properly formatting the
> address using paddr_to_iopte, which does not match up with the
> iopte_deref in __arm_lpae_map. This is incorrect for the LPAE pte
> format, as it does not handle the high bits properly.

Oh, I guess whatever system it was tested on can't have exercised it all
that thoroughly. IIRC I couldn't test it myself since at the time none
of the Fast Model builds with SMMUs actually implemented any memory
above 48 bits.

> This was found on Apple T6000 DARTs, which require a new pte format
> (different shift); adding support for that to
> paddr_to_iopte/iopte_to_paddr caused it to break badly, as even <48-bit
> addresses would end up incorrect in that case.

...I look forward to not wanting to look at that patch :)

> Signed-off-by: Hector Martin <marcan@marcan.st>
> ---
>   drivers/iommu/io-pgtable-arm.c | 14 +++++++-------
>   1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index dd9e47189d0d..b636e2737607 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -315,12 +315,12 @@ static int arm_lpae_init_pte(struct arm_lpae_io_pgtable *data,
>   static arm_lpae_iopte arm_lpae_install_table(arm_lpae_iopte *table,
>   					     arm_lpae_iopte *ptep,
>   					     arm_lpae_iopte curr,
> -					     struct io_pgtable_cfg *cfg)
> +					     struct arm_lpae_io_pgtable *data)
>   {

Please just define a local "cfg" variable here like in most other
places, to avoid the rest of the churn in this function. Other than
that,

Acked-by: Robin Murphy <robin.murphy@arm.com>

Also,

Fixes: 6c89928ff7a0 ("iommu/io-pgtable-arm: Support 52-bit physical address")

Thanks,
Robin.
(currently elbow-deep in other parts of io-pgtable-arm...)

>   	arm_lpae_iopte old, new;
>   
> -	new = __pa(table) | ARM_LPAE_PTE_TYPE_TABLE;
> -	if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS)
> +	new = paddr_to_iopte(__pa(table), data) | ARM_LPAE_PTE_TYPE_TABLE;
> +	if (data->iop.cfg.quirks & IO_PGTABLE_QUIRK_ARM_NS)
>   		new |= ARM_LPAE_PTE_NSTABLE;
>   
>   	/*
> @@ -332,11 +332,11 @@ static arm_lpae_iopte arm_lpae_install_table(arm_lpae_iopte *table,
>   
>   	old = cmpxchg64_relaxed(ptep, curr, new);
>   
> -	if (cfg->coherent_walk || (old & ARM_LPAE_PTE_SW_SYNC))
> +	if (data->iop.cfg.coherent_walk || (old & ARM_LPAE_PTE_SW_SYNC))
>   		return old;
>   
>   	/* Even if it's not ours, there's no point waiting; just kick it */
> -	__arm_lpae_sync_pte(ptep, 1, cfg);
> +	__arm_lpae_sync_pte(ptep, 1, &data->iop.cfg);
>   	if (old == curr)
>   		WRITE_ONCE(*ptep, new | ARM_LPAE_PTE_SW_SYNC);
>   
> @@ -380,7 +380,7 @@ static int __arm_lpae_map(struct arm_lpae_io_pgtable *data, unsigned long iova,
>   		if (!cptep)
>   			return -ENOMEM;
>   
> -		pte = arm_lpae_install_table(cptep, ptep, 0, cfg);
> +		pte = arm_lpae_install_table(cptep, ptep, 0, data);
>   		if (pte)
>   			__arm_lpae_free_pages(cptep, tblsz, cfg);
>   	} else if (!cfg->coherent_walk && !(pte & ARM_LPAE_PTE_SW_SYNC)) {
> @@ -592,7 +592,7 @@ static size_t arm_lpae_split_blk_unmap(struct arm_lpae_io_pgtable *data,
>   		__arm_lpae_init_pte(data, blk_paddr, pte, lvl, 1, &tablep[i]);
>   	}
>   
> -	pte = arm_lpae_install_table(tablep, ptep, blk_pte, cfg);
> +	pte = arm_lpae_install_table(tablep, ptep, blk_pte, data);
>   	if (pte != blk_pte) {
>   		__arm_lpae_free_pages(tablep, tablesz, cfg);
>   		/*
> 

      reply	other threads:[~2021-11-17 17:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-17 17:12 Hector Martin
2021-11-17 17:46 ` Robin Murphy [this message]

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=a2b45243-7e0a-a2ac-4e14-5256a3e7abb4@arm.com \
    --to=robin.murphy@arm.com \
    --cc=alyssa@rosenzweig.io \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=sven@svenpeter.dev \
    --cc=will@kernel.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

all inboxes | Powered by JetHome®