> Thanks for your reply. This isn't about a specific IOMMU. Let me
> describe the situation better:
>
> 1. I'm implementing the AMD IOMMU, which is a PCI IOMMU (not in the CPU).
> 2. Devices need address translation and checking through this IOMMU.
> 3. But in the future there might be other IOMMU implementations,
> possibly for other bus types.
>
> Yes, I could (and have already done to test my code) modify device code
> to ask the AMD IOMMU for translation. But we have stuff like AIO, which
> isn't really bus-specific and would result in spagetti code if I add
> PCI-specific stuff, then somebody else does the same for other buses and
> so on. Moreover, even for PCI, it isn't really straightforward to obtain
> the bus-device-function number required to do translation from AIO code
> (e.g. I needed to add the devfn or a pointer to the actual PCIDevice to
> BMDMAState to get it working for PIIX).
A bus-device-function number is inherently PCI specific.
> So I considered providing a generic IOMMU translation/checking API that
> could be used by all devices and all IOMMUs. Generally getting the
> {PCI,ISA,Whatever}Device should be enough, I think.
>
> If the IOMMU can't handle that specific bus, that's no problem, we can
> have generic code do identity mapping without any access checking. If
> somebody comes along and wants to implement another IOMMU emulation, all
> he needs is to provide implementations for those functions.
The actual code to handle address remapping can be bus agnostic. The code to
create the mappings is inherently bus specific. i.e. the generic code needs to
ask the bus bridge "how do I translate this access onto your parent bus".
For example, consider a PCI bridge (Device A) with an IOMMU. On that PCI bus
resides a PCI-ISA bridge (Device B) that also has an IOMMU. Device C is a bus-
master ISA device[1].
Accesses from device C cause the memory mapping code to walk down the bus
structure. First the ISA IOMMU translates that into an access from device B.
Then the PCI IOMMU translates this into a system bus access from device A.
The code to determine each of these mappings is inherently bus specific. That
code trivially knows how to access bus-specific information from its devices.
However the framework used to chain these mappings and perform the actual
transfer should be bus agnostic.
While the IOMMU actually resides in the host bridge, it probably makes most
sense to associate it with the bus itself. When the host device creates the
bus it can also create the IOMMU. This should handle both explicit (PCI) and
implicit (SBUS) slave-side bus interfaces.
Paul
[1] I don't think ISA supports bus-master devices, but ignore that for now.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
