linux-kernel - RE: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <C5ECD7A89D1DC44195F34B25E172658D1A49A2@039-SN2MPN1-013.039d.mgd.msft.net>
Date:	Thu, 20 Sep 2012 09:46:32 +0000
From:	Sethi Varun-B16395 <B16395@...escale.com>
To:	Wood Scott-B07421 <B07421@...escale.com>,
	Kumar Gala <galak@...nel.crashing.org>
CC:	"joerg.roedel@....com" <joerg.roedel@....com>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes
 required by fsl PAMU driver.



> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, September 20, 2012 5:42 AM
> To: Kumar Gala
> Cc: Sethi Varun-B16395; joerg.roedel@....com; iommu@...ts.linux-
> foundation.org; linuxppc-dev@...ts.ozlabs.org; linux-
> kernel@...r.kernel.org; Sethi Varun-B16395
> Subject: Re: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes
> required by fsl PAMU driver.
> 
> On 09/19/2012 08:52:27 AM, Kumar Gala wrote:
> >
> > On Sep 19, 2012, at 8:17 AM, <b16395@...escale.com>
> > <b16395@...escale.com> wrote:
> >
> > > From: Varun Sethi <Varun.Sethi@...escale.com>
> > >
> > > Added the following domain attributes required by FSL PAMU driver:
> > > 1. Subwindows field added to the iommu domain geometry attribute.
> > > 2. Added new iommu stash attribute, which allows setting of the
> > >   LIODN specific stash id parameter through IOMMU API.
> > > 3. Added an attribute for enabling/disabling DMA to a particular
> > >   memory window.
> > >
> > > Signed-off-by: Varun Sethi <Varun.Sethi@...escale.com>
> > > ---
> > > include/linux/iommu.h |   30 ++++++++++++++++++++++++++++++
> > > 1 files changed, 30 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h index
> > > 7e83370..eaa40c6 100644
> > > --- a/include/linux/iommu.h
> > > +++ b/include/linux/iommu.h
> > > @@ -44,6 +44,28 @@ struct iommu_domain_geometry {
> > > 	dma_addr_t aperture_start; /* First address that can be
> > mapped    */
> > > 	dma_addr_t aperture_end;   /* Last address that can be
> > mapped     */
> > > 	bool force_aperture;       /* DMA only allowed in mappable
> > range? */
> > > +
> > > +	/* The subwindows field indicates number of DMA subwindows
> > supported
> > > +	 * by the geometry. Following is the interpretation of
> > > +	 * values for this field:
> > > +	 * 0 : This implies that the supported geometry size is 1 MB
> > > +         * with each subwindow size being 4KB. Thus number of
> > subwindows
> > > +	 * being = 1MB/4KB = 256.
> > > +	 * 1 : Only one DMA window i.e. no subwindows.
> > > +	 * value other than 0 or 1 would indicate actual number of
> > subwindows.
> > > +	 */
> > > +	u32 subwindows;
> > > +};
> > > +
> > > +/* This attribute corresponds to IOMMUs capable of generating
> > > + * a stash transaction. A stash transaction is typically a
> > > + * hardware initiated prefetch of data from memory to cache.
> > > + * This attribute allows configuring stashig specific parameters
> > > + * in the IOMMU hardware.
> > > + */
> > > +struct iommu_stash_attribute {
> > > +	u32 	cpu;	/* cpu number */
> > > +	u32 	cache;	/* cache to stash to: L1,L2,L3 */
> >
> > seems like this should be enum instead of u32 for cache
> >
> > With enum being something like:
> >
> > enum iommu_attr_stash_cache {
> > 	IOMMU_ATTR_CACHE_L1,
> > 	IOMMU_ATTR_CACHE_L2,
> > 	IOMMU_ATTR_CACHE_L3,
> > };
> 
> Don't we want these structs to be usable via some VFIO ioctl?  In that
> case they need to use fixed size types.
> 
Yes, this would be usable via vfio ioctl. But, then the caller should be
aware of supported stash targets. May be I should add an interface for the caller,
to query supported stash targets.

-Varun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/