From mboxrd@z Thu Jan 1 00:00:00 1970 From: Varun Sethi Subject: RE: your mail Date: Wed, 26 Feb 2014 12:14:38 +0000 Message-ID: <74d3514e1ab74eb5ab0234596745fb50@BL2PR03MB468.namprd03.prod.outlook.com> References: <20140224172850.GG2553@mudshark.cambridge.arm.com> <42a1041ac2df4a73a94dc4516969e35d@BL2PR03MB468.namprd03.prod.outlook.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1231349967331023674==" Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: srikanth TS Cc: Will Deacon , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org" List-Id: iommu@lists.linux-foundation.org --===============1231349967331023674== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_74d3514e1ab74eb5ab0234596745fb50BL2PR03MB468namprd03pro_" --_000_74d3514e1ab74eb5ab0234596745fb50BL2PR03MB468namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: srikanth TS [mailto:srikantht.shivanand-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] Sent: Wednesday, February 26, 2014 1:53 PM To: Sethi Varun-B16395 Cc: sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Will Deacon; = iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org Subject: RE: your mail On Feb 25, 2014 8:28 PM, "Varun Sethi" > wrote: > > > > > -----Original Message----- > > From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu- > > bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Will Deacon > > Sent: Monday, February 24, 2014 10:59 PM > > To: srikanth TS > > Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; linu= x- > > kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ts.srikanth@sams= ung.com > > Subject: Re: your mail > > > > On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote: > > > Hi Will Deacon, > > > > Hello, > > > > > Currently SMMU driver expecting all stream ID used by respective > > > master should be defined in the DT. > > > > > > We want to know how to handle in the case of virtual functions > > > dynamically created and destroyed. > > > > > > Is PCI driver responsible for creating stream ID respective BDand > > > requesting SMMU to add to the mapping table[stream Id to context > > > mapping table]? > > > > > > Or is there any right way of doing it? > > > > Correct, the driver currently doesn't support dynamic mappings (mainly > > because I didn't want to try and invent something that I couldn't test)= . > > > > There are a couple of ways to solve this: > > > > (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SM= MU > > within a fixed range. That would probably need some code in the b= us > > layer, so that a bus notifier can kick and call back to the > > relevant > > SMMU. > This could be done in add device notifier. I am working on similar(not PC= I) hot plug device infrastructure for arm smmu driver. I will post an RFC p= atch by next week. Can you please explain with little more detail. We just want to make sure y= our idea fits in for pci iov also. [Sethi Varun-B16395] In the add device notifier we can allocate the streamI= D (and the corresponding smmu master), while allocating the iommu group for= the PCI devices. All, the PCIe devices sharing the same iommu group would = share the stream ID. Currently, I am working on a add device framework for= hot plug devices. -Varun --_000_74d3514e1ab74eb5ab0234596745fb50BL2PR03MB468namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

 <= /p>

From: srikanth= TS [mailto:srikantht.shivanand-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: Wednesday, February 26, 2014 1:53 PM
To: Sethi Varun-B16395
Cc: sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Will D= eacon; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
Subject: RE: your mail

 


On Feb 25, 2014 8:28 PM, "Varun Sethi" <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>
>
>
> > -----Original Message-----
> > From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
> > bounces@lis= ts.linux-foundation.org] On Behalf Of Will Deacon
> > Sent: Monday, February 24, 2014 10:59 PM
> > To: srikanth TS
> > Cc: iommu@lis= ts.linux-foundation.org; sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; linux-
> > kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org<= /a>; ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
> > Subject: Re: your mail
> >
> > On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:<= br> > > > Hi Will Deacon,
> >
> > Hello,
> >
> > > Currently SMMU driver expecting all stream ID used by respec= tive
> > > master should be defined in the DT.
> > >
> > > We want to know how to handle in the case of virtual functio= ns
> > > dynamically created and destroyed.
> > >
> > > Is PCI driver responsible for creating stream ID respective = BDand
> > > requesting SMMU to add to the mapping table[stream Id to con= text
> > > mapping table]?
> > >
> > > Or is there any right way of doing it?
> >
> > Correct, the driver currently doesn't support dynamic mappings (m= ainly
> > because I didn't want to try and invent something that I couldn't= test).
> >
> > There are a couple of ways to solve this:
> >
> >   (1) Add a way for a PCI RC to dynamically allocate StreamI= Ds on an SMMU
> >       within a fixed range. That would probably ne= ed some code in the bus
> >       layer, so that a bus notifier can kick and c= all back to the
> > relevant
> >       SMMU.
> This could be done in add device notifier. I am working on similar(not= PCI) hot plug device infrastructure for arm smmu driver. I will post an RF= C patch by next week.
Can you please explain with little more detail. We just want to make sure y= our idea fits in for pci iov also.

[Sethi Varun-B16395] In the add device notifier we can= allocate the streamID (and the corresponding smmu master), while allocatin= g the iommu group for the PCI devices. All, the PCIe devices sharing the same iommu group would share the stream ID.  Currently, I= am working on a add device framework for hot plug devices.

-Varun

--_000_74d3514e1ab74eb5ab0234596745fb50BL2PR03MB468namprd03pro_-- --===============1231349967331023674== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1231349967331023674==--