From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
To: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
"tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org"
<tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"robert.richter-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org"
<robert.richter-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>,
"linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org"
<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH] iommu/arm-smmu-v2: ThunderX(errata-23399) mis-extends 64bit registers
Date: Thu, 30 Jul 2015 20:08:57 +0100 [thread overview]
Message-ID: <55BA7649.3080608@arm.com> (raw)
In-Reply-To: <20150730184523.GC16663-5wv7dgnIgG8@public.gmane.org>
On 30/07/15 19:45, Will Deacon wrote:
> Hello,
>
> On Thu, Jul 30, 2015 at 06:55:06PM +0100, tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org wrote:
>> From: Tirumalesh Chalamarla <tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
>>
>> The SMMU architecture defines two different behaviors when 64-bit
>> registers are written with 32-bit writes. The first behavior causes
>> zero extension into the upper 32-bits. The second behavior splits a
>> 64-bit register into "normal" 32-bit register pairs.
>>
>> On some passes of ThunderX,
>> the following registers incorrectly zero extended when they should
>> instead behave as normal 32-bit register pairs:
>>
>> SMMU()_(S)GFAR
>> SMMU()_NSGFAR
>> SMMU()_CB()_TTBR0
>> SMMU()_CB()_TTBR1
>> SMMU()_CB()_FAR
>>
>> Signed-off-by: Tirumalesh Chalamarla <tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
>> ---
>> drivers/iommu/arm-smmu.c | 51 ++++++++++++++++++++++++++++++++++--------------
>> 1 file changed, 36 insertions(+), 15 deletions(-)
>
> [...]
>
>> @@ -762,22 +766,39 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>>
>> /* TTBRs */
>> if (stage1) {
>> - reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>> - writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
>> - reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0] >> 32;
>> - reg |= ARM_SMMU_CB_ASID(cfg) << TTBRn_HI_ASID_SHIFT;
>> - writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_HI);
>> -
>> - reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
>> - writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR1_LO);
>> - reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1] >> 32;
>> - reg |= ARM_SMMU_CB_ASID(cfg) << TTBRn_HI_ASID_SHIFT;
>> - writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR1_HI);
>> + if (smmu->options & ARM_SMMU_OPT_64BIT_WRITES_ONLY) {
>> + reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>> + reg64 |= ((u64) ARM_SMMU_CB_ASID(cfg)) <<
>> + (TTBRn_HI_ASID_SHIFT + 32);
>> + writeq_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
>> +
>> + reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
>> + reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) <<
>> + (TTBRn_HI_ASID_SHIFT + 32);
>> + writeq_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR1_LO);
>> + } else {
>> + reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>> + writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
>> + reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0] >> 32;
>> + reg |= ARM_SMMU_CB_ASID(cfg) << TTBRn_HI_ASID_SHIFT;
>> + writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_HI);
>> +
>> + reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
>> + writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR1_LO);
>> + reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1] >> 32;
>> + reg |= ARM_SMMU_CB_ASID(cfg) << TTBRn_HI_ASID_SHIFT;
>> + writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR1_HI);
>> + }
>
> I'm fine with making this sort of change if you need it, but this is pretty
> ugly. Worse, it won't compile for 32-bit ARM.
>
> How about we add a wrapper around these, say smmu_writeq(...), which can
> then either expand to 2x writel_relaxed or 1x writeq_relaxed depending on
> CONFIG_64BIT and your erratum workaround?
Would we even need a specific erratum workaround then? I don't see an
issue with always using writeq on 64-bit, and there's not much we can do
for 32-bit if it has no way to write the upper half of the TTBR on this
thing.
Robin.
>
> Don't forgot to update the ATOS code too (so you need to write the high word
> first).
>
> Will
> _______________________________________________
> iommu mailing list
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
WARNING: multiple messages have this Message-ID (diff)
From: robin.murphy@arm.com (Robin Murphy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] iommu/arm-smmu-v2: ThunderX(errata-23399) mis-extends 64bit registers
Date: Thu, 30 Jul 2015 20:08:57 +0100 [thread overview]
Message-ID: <55BA7649.3080608@arm.com> (raw)
In-Reply-To: <20150730184523.GC16663@arm.com>
On 30/07/15 19:45, Will Deacon wrote:
> Hello,
>
> On Thu, Jul 30, 2015 at 06:55:06PM +0100, tchalamarla at caviumnetworks.com wrote:
>> From: Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
>>
>> The SMMU architecture defines two different behaviors when 64-bit
>> registers are written with 32-bit writes. The first behavior causes
>> zero extension into the upper 32-bits. The second behavior splits a
>> 64-bit register into "normal" 32-bit register pairs.
>>
>> On some passes of ThunderX,
>> the following registers incorrectly zero extended when they should
>> instead behave as normal 32-bit register pairs:
>>
>> SMMU()_(S)GFAR
>> SMMU()_NSGFAR
>> SMMU()_CB()_TTBR0
>> SMMU()_CB()_TTBR1
>> SMMU()_CB()_FAR
>>
>> Signed-off-by: Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
>> ---
>> drivers/iommu/arm-smmu.c | 51 ++++++++++++++++++++++++++++++++++--------------
>> 1 file changed, 36 insertions(+), 15 deletions(-)
>
> [...]
>
>> @@ -762,22 +766,39 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>>
>> /* TTBRs */
>> if (stage1) {
>> - reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>> - writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
>> - reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0] >> 32;
>> - reg |= ARM_SMMU_CB_ASID(cfg) << TTBRn_HI_ASID_SHIFT;
>> - writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_HI);
>> -
>> - reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
>> - writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR1_LO);
>> - reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1] >> 32;
>> - reg |= ARM_SMMU_CB_ASID(cfg) << TTBRn_HI_ASID_SHIFT;
>> - writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR1_HI);
>> + if (smmu->options & ARM_SMMU_OPT_64BIT_WRITES_ONLY) {
>> + reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>> + reg64 |= ((u64) ARM_SMMU_CB_ASID(cfg)) <<
>> + (TTBRn_HI_ASID_SHIFT + 32);
>> + writeq_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
>> +
>> + reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
>> + reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) <<
>> + (TTBRn_HI_ASID_SHIFT + 32);
>> + writeq_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR1_LO);
>> + } else {
>> + reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>> + writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
>> + reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0] >> 32;
>> + reg |= ARM_SMMU_CB_ASID(cfg) << TTBRn_HI_ASID_SHIFT;
>> + writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_HI);
>> +
>> + reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
>> + writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR1_LO);
>> + reg = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1] >> 32;
>> + reg |= ARM_SMMU_CB_ASID(cfg) << TTBRn_HI_ASID_SHIFT;
>> + writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR1_HI);
>> + }
>
> I'm fine with making this sort of change if you need it, but this is pretty
> ugly. Worse, it won't compile for 32-bit ARM.
>
> How about we add a wrapper around these, say smmu_writeq(...), which can
> then either expand to 2x writel_relaxed or 1x writeq_relaxed depending on
> CONFIG_64BIT and your erratum workaround?
Would we even need a specific erratum workaround then? I don't see an
issue with always using writeq on 64-bit, and there's not much we can do
for 32-bit if it has no way to write the upper half of the TTBR on this
thing.
Robin.
>
> Don't forgot to update the ATOS code too (so you need to write the high word
> first).
>
> Will
> _______________________________________________
> iommu mailing list
> iommu at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
next prev parent reply other threads:[~2015-07-30 19:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-30 17:55 [PATCH] iommu/arm-smmu-v2: ThunderX(errata-23399) mis-extends 64bit registers tchalamarla
2015-07-30 17:55 ` tchalamarla at caviumnetworks.com
[not found] ` <1438278906-29627-1-git-send-email-tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2015-07-30 18:45 ` Will Deacon
2015-07-30 18:45 ` Will Deacon
[not found] ` <20150730184523.GC16663-5wv7dgnIgG8@public.gmane.org>
2015-07-30 19:07 ` Chalamarla, Tirumalesh
[not found] ` <96AD8EF9-D416-43AB-BA6F-2C25098BB8BB-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2015-07-30 20:54 ` Chalamarla, Tirumalesh
[not found] ` <91236962-23EF-4306-B0FA-0F7DAE4F06CD-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2015-07-31 11:27 ` Will Deacon
2015-07-31 11:27 ` Will Deacon
2015-07-31 11:48 ` Russell King - ARM Linux
2015-07-31 11:48 ` Russell King - ARM Linux
2015-07-30 19:08 ` Robin Murphy [this message]
2015-07-30 19:08 ` Robin Murphy
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=55BA7649.3080608@arm.com \
--to=robin.murphy-5wv7dgnigg8@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=robert.richter-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org \
--cc=tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.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 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.