Re: [PATCH 2/6] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute

From: Joerg Roedel
Date: Mon Jan 30 2012 - 09:49:20 EST


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@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/