From: Jerome Glisse <j.glisse@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Jerome Glisse <jglisse@redhat.com>,
ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Core Kernel support for Compute-Offload Devices
Date: Mon, 3 Aug 2015 17:34:44 -0400 [thread overview]
Message-ID: <20150803213443.GE2981@gmail.com> (raw)
In-Reply-To: <1438636374.26511.440.camel@infradead.org>
On Mon, Aug 03, 2015 at 10:12:54PM +0100, David Woodhouse wrote:
> On Mon, 2015-08-03 at 23:10 +0200, Joerg Roedel wrote:
> > On Mon, Aug 03, 2015 at 03:01:45PM -0400, Jerome Glisse wrote:
> > > This is not the case with current AMD hw which IIRC only support 8bits or
> > > 9bits for PASID. Dunno if there next hardware will have more bits or not.
> > > So i need to check PCIE spec but i do not think the 20bits is a mandatory
> > > limit.
> >
> > AMD hardware currently implements PASIDs with 16 bits. Given that only
> > mm_structs which are used by offload devices get one, this should be
> > enough to put them into a global pool and have one PASID per mm_struct.
>
> I think there are many ARM systems which need this model because of the
> way TLB shootdowns are handled in hardware, and shared with the IOMMU?
> So we have to use the same ASID for both MMU and IOMMU there, AIUI.
>
> Not that I claim to be an expert on the ARM IOMMUs.
>
I see that on some platform the ASID <-> page table must be a 1 to 1
relationship. My experience so far on AMD is that it does not and that
while the IOMMU have 16bits their GPU have 9 or 8 bits. Also given that
PASID spec says that device can support different number of bits, it
seems that this gonna end up being a mess with all of specific arch/device
quirks.
Note that i really would like the ASID <-> mm struct 1 to 1 match but
i am just fearing this is not something that can be common to all
platform.
Cheers,
Jérôme
next prev parent reply other threads:[~2015-08-03 21:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-30 13:00 Joerg Roedel
2015-07-30 13:31 ` David Woodhouse
2015-07-30 13:54 ` Joerg Roedel
2015-07-31 16:34 ` Jerome Glisse
2015-08-03 18:51 ` David Woodhouse
2015-08-03 19:01 ` Jerome Glisse
2015-08-03 19:07 ` Andy Lutomirski
2015-08-03 19:56 ` Jerome Glisse
2015-08-03 21:10 ` Joerg Roedel
2015-08-03 21:12 ` David Woodhouse
2015-08-03 21:31 ` Joerg Roedel
2015-08-03 21:34 ` Jerome Glisse [this message]
2015-08-03 21:51 ` David Woodhouse
2015-08-04 18:11 ` Catalin Marinas
2015-08-03 22:10 ` Benjamin Herrenschmidt
2015-07-30 22:32 ` Benjamin Herrenschmidt
2015-08-01 16:10 ` Joerg Roedel
2015-07-31 14:52 ` Rik van Riel
2015-07-31 16:13 ` Jerome Glisse
2015-08-01 15:57 ` Joerg Roedel
2015-08-01 19:08 ` Jerome Glisse
2015-08-03 16:02 ` Joerg Roedel
2015-08-03 18:28 ` Jerome Glisse
2015-08-01 20:46 ` Arnd Bergmann
2015-08-03 16:10 ` Joerg Roedel
2015-08-03 19:23 ` Arnd Bergmann
2015-08-04 15:40 ` Christoph Lameter
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=20150803213443.GE2981@gmail.com \
--to=j.glisse@gmail.com \
--cc=dwmw2@infradead.org \
--cc=jglisse@redhat.com \
--cc=ksummit-discuss@lists.linuxfoundation.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