Re: [Qemu-devel] [0/8] RFC: VFIO and guest side IOMMUs, revisited

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3821 bytes --]

On Tue, May 14, 2013 at 11:58:16AM +0200, Paolo Bonzini wrote:
> -----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)

Yeah, that's probably ok, especially if we can think of good names for
the two bus parameters to make the distinction clear.

> and almost the same, since the host bridge is just a container_of away
> from pci_bus0.

Well, bus->qbus.parent_dev and then one of the suitable class wrappers
on container_of().

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]