From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: "Chalamarla,
Tirumalesh"
<Tirumalesh.Chalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
linux-arm-kernel
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: iommu/arm-smmu-v2 ASID/VMID calculation
Date: Mon, 25 Jan 2016 17:03:13 +0000 [thread overview]
Message-ID: <20160125170312.GJ22927@arm.com> (raw)
In-Reply-To: <198F501C-8D30-4EB5-BC40-4F40BB75D40B-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
On Thu, Jan 21, 2016 at 06:52:34PM +0000, Chalamarla, Tirumalesh wrote:
> Hi Will,
Hello,
> Current ASID/VMID calculation logic makes lot of assumption about internal TLB
> implementation of SMMU,
Not really. It makes assumptions that the hardware follows the architecture,
which is hardly unreasonable as a starting point.
> Systems like ThunderX have more than one smmu in the system and it can use same
> TLBs with more than one of them and expects ASID to be unique
... but that's broken. If you built a system where the CPUs shared a TLB,
you would run into issues as well.
How does this work with things like arm_smmu_tlb_sync and the TLBGSTATUS
register?
> Current logic
>
> #define ARM_SMMU_CB_ASID(cfg) ((cfg)->cbndx)
> #define ARM_SMMU_CB_VMID(cfg) ((cfg)->cbndx + 1)
>
>
> Can this be replaced by something like
>
>
> #define ARM_SMMU_CB_ASID(cfg, smmu) (((smmu)->idx << (smmu)->asid_shift) | (cfg)->cbndx)
> #define ARM_SMMU_CB_VMID(cfg, smmu) (((smmu)->idx << (smmu)->vmid_shift) | (cfg)->cbndx + 1)
>
>
> Idx and shift can be passed from device-tree.
>
>
> Please let me know if this is acceptable, I will prepare a proper patch
> and send to list.
>
>
> If this is not acceptable through an alternative suggestion.
If we're going to put something into the device-tree, then it should be
an erratum property describing the offset to be applied to ASID/VMIDs.
You also need to take care not to describe overlapping numberspaces.
How many context banks do you implement in each SMMU?
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: iommu/arm-smmu-v2 ASID/VMID calculation
Date: Mon, 25 Jan 2016 17:03:13 +0000 [thread overview]
Message-ID: <20160125170312.GJ22927@arm.com> (raw)
In-Reply-To: <198F501C-8D30-4EB5-BC40-4F40BB75D40B@caviumnetworks.com>
On Thu, Jan 21, 2016 at 06:52:34PM +0000, Chalamarla, Tirumalesh wrote:
> Hi Will,
Hello,
> Current ASID/VMID calculation logic makes lot of assumption about internal TLB
> implementation of SMMU,
Not really. It makes assumptions that the hardware follows the architecture,
which is hardly unreasonable as a starting point.
> Systems like ThunderX have more than one smmu in the system and it can use same
> TLBs with more than one of them and expects ASID to be unique
... but that's broken. If you built a system where the CPUs shared a TLB,
you would run into issues as well.
How does this work with things like arm_smmu_tlb_sync and the TLBGSTATUS
register?
> Current logic
>
> #define ARM_SMMU_CB_ASID(cfg) ((cfg)->cbndx)
> #define ARM_SMMU_CB_VMID(cfg) ((cfg)->cbndx + 1)
>
>
> Can this be replaced by something like
>
>
> #define ARM_SMMU_CB_ASID(cfg, smmu) (((smmu)->idx << (smmu)->asid_shift) | (cfg)->cbndx)
> #define ARM_SMMU_CB_VMID(cfg, smmu) (((smmu)->idx << (smmu)->vmid_shift) | (cfg)->cbndx + 1)
>
>
> Idx and shift can be passed from device-tree.
>
>
> Please let me know if this is acceptable, I will prepare a proper patch
> and send to list.
>
>
> If this is not acceptable through an alternative suggestion.
If we're going to put something into the device-tree, then it should be
an erratum property describing the offset to be applied to ASID/VMIDs.
You also need to take care not to describe overlapping numberspaces.
How many context banks do you implement in each SMMU?
Will
next prev parent reply other threads:[~2016-01-25 17:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-21 18:52 iommu/arm-smmu-v2 ASID/VMID calculation Chalamarla, Tirumalesh
[not found] ` <198F501C-8D30-4EB5-BC40-4F40BB75D40B-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2016-01-25 17:03 ` Will Deacon [this message]
2016-01-25 17:03 ` Will Deacon
[not found] ` <20160125170312.GJ22927-5wv7dgnIgG8@public.gmane.org>
2016-01-26 0:48 ` Chalamarla, Tirumalesh
2016-01-26 0:48 ` Chalamarla, Tirumalesh
[not found] ` <E978AB4F-5CB0-42D8-8152-04C77DB664A1-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2016-01-26 3:11 ` Chalamarla, Tirumalesh
2016-01-26 3:11 ` Chalamarla, Tirumalesh
[not found] ` <6F24A28A-6302-4C48-A933-B47A9735808C-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2016-01-26 11:48 ` Robin Murphy
2016-01-26 11:48 ` Robin Murphy
[not found] ` <56A75D0A.7000806-5wv7dgnIgG8@public.gmane.org>
2016-01-27 19:05 ` Chalamarla, Tirumalesh
2016-01-27 19:05 ` Chalamarla, Tirumalesh
2016-01-26 11:54 ` Will Deacon
2016-01-26 11:54 ` Will Deacon
[not found] ` <20160126115435.GB21553-5wv7dgnIgG8@public.gmane.org>
2016-01-27 19:06 ` Chalamarla, Tirumalesh
2016-01-27 19:06 ` Chalamarla, Tirumalesh
[not found] ` <E0484253-BE37-476A-9F4A-ABE6B74EC174-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2016-01-27 19:08 ` Will Deacon
2016-01-27 19:08 ` Will Deacon
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=20160125170312.GJ22927@arm.com \
--to=will.deacon-5wv7dgnigg8@public.gmane.org \
--cc=Tirumalesh.Chalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@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.