linux-kernel - Re: [PATCH 2/6] iommu/amd: Implement DOMAIN_ATTR

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20120130144909.GT19255@amd.com>
Date:	Mon, 30 Jan 2012 15:49:09 +0100
From:	Joerg Roedel <joerg.roedel@....com>
To:	Ohad Ben-Cohen <ohad@...ery.com>
CC:	<iommu@...ts.linux-foundation.org>, <linux-kernel@...r.kernel.org>,
	David Woodhouse <dwmw2@...radead.org>,
	David Brown <davidb@...eaurora.org>,
	Tony Lindgren <tony@...mide.com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Stuart Yoder <b08248@...il.com>,
	Scott Wood <scottwood@...escale.com>,
	Hiroshi Doyu <hdoyu@...dia.com>
Subject: Re: [PATCH 2/6] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute

On Sat, Jan 28, 2012 at 10:44:22PM +0200, Ohad Ben-Cohen wrote:
> On Fri, Jan 27, 2012 at 3:03 PM, Joerg Roedel <joerg.roedel@....com> wrote:
> > Note that only the read-side is handled by the core. An IOMMU driver may
> > decide to implement a write-side for the geometry which would be not in
> > the core then. Having a dedicated function for the write-side does not
> > make sense because (for now) there is only one upcoming driver requiring
> > this.
> 
> I'd still go with a type-safe interface here, but maybe it's only me.

Well, the idea still stands to replace 'void *data' with something like
'union domain_attr *data'. This isn't as type-safe as dedicated
functions, but still better than void*.

> I'm not so sure how would drivers use these "hardware-specific api
> attr extensions" in general.

Depends on the attribute. For the geometry attribute drivers that
allocate a domain should read out the geometry and only use the range
returned for map/unmap (or fail initialization when the domain geometry
is unexpected).

> Is the intention that only hardware-specific drivers will use them ? I
> guess that generic drivers won't be able to use them, because their
> behavior will not be well-defined across all hardware implementations.

Hardware specific attributes are intended, but not limited to hardware
specific drivers. A generic driver that _may_ run on a given hardware
can use a hardware specific attribute too. If it doesn't run on this
hardware it will just get -EINVAL back.

Regards,

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

--
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/