-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 14/05/2013 04:39, David Gibson ha scritto: > On Mon, May 13, 2013 at 03:30:26PM +0200, Paolo Bonzini wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Il 13/05/2013 15:13, David Gibson ha scritto: >>> On Mon, May 13, 2013 at 02:23:30PM +0200, Paolo Bonzini wrote: >>>> Il 13/05/2013 12:54, David Gibson ha scritto: >>>>> Specifically the way the iommu is determined from a >>>>> callback in the PCIBus means that it won't be assigned for >>>>> devices under a PCI-PCI bridge. >>>> >>>> Right. I saw the report from Alexey, but I am a bit wary of >>>> touching it because it's not a regression. In fact there >>>> is even a FIXME for it: >>>> >>>> /* FIXME: inherit memory region from bus creator */ >>> >>> Uh.. sort of. >>> >>>> Perhaps we can make pci_iommu_as a Bus method, where the >>>> default implementation looks up along the chain, and the end >>>> of the recursion is in SysBus or in PCI buses that have set >>>> the callback. >>> >>> So, this is complicated by the fact that there are two cases, >>> and they can both be found in existing hardware. >>> >>> 1) One is where devices behind the bridge are not visible / >>> differentiable to the IOMMU, and so effectively all their DMAs >>> originate from the bridge device itself. In this case the >>> correct thing is to give all devices under the bridge the same >>> DMA AddressSpace as the bridge device, as suggested by the >>> FIXME. This will be typical behaviour for PCI-E to PCI >>> bridges. >>> >>> 2) The other case is where the bridge passes through RIDs, so >>> that the IOMMU can still differentiate devices behind it. For >>> this case, we really want the hook to be in the host bridge / >>> root bus, and it can make a decision based on the full >>> bus/dev/fn information. This will be typical for PCI-E to >>> PCI-E bridges (or switches or nexuses or whatever they're >>> usually called for PCI-E). This case will be very important as >>> we start to model newer PCI-E based machines by default, where >>> typically *all* devices are behind a logical p2p bridge inside >>> the root complex (but are still differentiable by the Intel >>> IOMMU amongst others). >>> >>> I'm not sure at this stage how to properly handle both cases. >> >> Suppose you have a host bridge pci_bus0 and a PCIE->PCIE bridge >> pci_bus1. pci_bus1 does not define a IOMMU callback, pci_bus0 >> does. >> >> Would it work to use the PCIBus callback provided by pci_bus0, >> but invoke it as >> >> pci_bus0->iommu_fn(pci_bus1, pci_bus0->iommu_opaque, devfn) > > Hrm. I'm a bit nervous about that, because I think when writing > an iommu_fn it would be very easy to forget that it could be called > with a bus other than the one the hook is attached to - and e.g. > assuming they can use bus->qbus.parent_dev to get to the host > bridge.
I think we can fix that by removing the opaque, and just passing in the PCIBus. Then it's more obvious pci_bus0->iommu_fn(pci_bus0, pci_bus1, devfn) and almost the same, since the host bridge is just a container_of away from pci_bus0. Paolo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRkgq4AAoJEBvWZb6bTYbyDeUP/RyQrKYOJAg7LX7Pj6ZyK4Dh kH2FN7HimDG1/zWxc91wgRBOT5Q49kHlQvirSHfgvaTcEZs15rfNRrSqi0SisZGQ 2e4Dvxwv3YNIsc9hSvCa14QwZnWsQ2iQYepHMP5zQJ5FWr5OLrqEKWTwM3bsAcli iYyDPWG4p+6knog5hIDLQ+/3TdJgRW5pLY4ZeYdDVB4azdRUpEn/OhYYT4tqrnMU lZuinAYR/gF2vrnEc9RbDlRy+SVBn69oAfTnbsvQKkD5HAWD7NFEhIPd/HS/DoWz KWyGBccXdgPvmRFkCmnRNnVUlvPziZNYZlS+vrTW8BiQS6C/ZZOuYyPpIzpHeAb+ t/Ds7nuQzzqj2kJIZlbhiRlEIXzLkXwcsZg8IW1Q1/wANprwYl2S6xyP9qhjUDDm mjZOfD+miWoOmxAzK5RiWM+jhiN+EaZLLrwxjzxR6w50/T2sqa3AJxSasTsZtLLl NaMX1bHnpcYA2XTMsMWEoReprvm5mBEcgAfzr5X2+uCd4GdI3/hfCgBkn4LCB5wp vi8rwQZ0ULcHqV8qs2iEEGNwt7IAs/XAS/yCr3RQ9bd6cabAQyMMFIXqE5YHAU60 jh3cVQcr2TjT1+dFP/+kVnNmwHKiVcbu7EhAhg/NHGoxnKxcMRI7Iy1tQvBivEe6 Hxojhub17ah3JdB4vOOW =Zz9q -----END PGP SIGNATURE-----
