linux-kernel - Re: [PATCH 02/10] Driver core: Add iommu_ops to bus

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: <20110908085842.GD31674@8bytes.org>
Date:	Thu, 8 Sep 2011 10:58:42 +0200
From:	Joerg Roedel <joro@...tes.org>
To:	Don Dutile <ddutile@...hat.com>
Cc:	Greg KH <gregkh@...e.de>, Ohad Ben-Cohen <ohad@...ery.com>,
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	iommu@...ts.linux-foundation.org,
	David Brown <davidb@...eaurora.org>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 02/10] Driver core: Add iommu_ops to bus_type

On Wed, Sep 07, 2011 at 04:37:11PM -0400, Don Dutile wrote:
> On 09/07/2011 03:44 PM, Greg KH wrote:

>> Why are you pushing this down into the driver core?  What other busses
>> becides PCI use/need this?
>>
>> If you can have a different IOMMU driver on the same bus, then wouldn't
>> this be a per-device thing instead of a per-bus thing?
>>
> And given the dma api takes a struct device *, it'd be more efficient
> to be tied into the device structure.

More efficient in what way? Currently no dma-api implementation uses the
iommu-api directly. It is planned to change that, of course. But the
dma-api implementation will use the iommu_map/iommu_unmap functions which
get an iommu_domain parameter and no device structure. Thats why the
domain structure keeps an iommu_ops pointer too.

> Device structure would get iommu ops set by parent(bus);
> if a bus (segment) doesn't provide a unique/different/layered IOMMU
> then the parent bus, it inherits the parent's iommu-ops.
> setting the iommu-ops in the root bus struct, seeds the iommu-ops
> for the (PCI) tree.
>
> For intel & amd IOMMUs, in early pci (bios,root?) init, you would
> seed the pci root busses with appropriate IOMMU support (based on
> dmar/drhd & ivrs/ivhd data structures, respectively), and
> then modify the PCI code to do the inheritence (PPB code inherits
> unless specific device driver for a given PPB vid-did loads a
> different iommu-ops for that segment/branch).
>
> This would enable different types of IOMMUs for different devices
> (or PCI segments, or branches of PCI trees) that are designed for
> different tasks -- simple IOMMUs for legacy devices; complicated, io-page-faulting
> IOMMUs for plug-in, high-end devices on virtualizing servers for PCI (SRIOV) endpoints.

This only works for pci, but the iommu-api is not pci-only.

> and as Greg indicates, is only relevant to PCI.

We already have non-pci iommu drivers implementing the iommu-api. So
this is certainly relevant outside pci too.

	Joerg

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