Re: [PATCH] VT-d: fix PCI device detach from virtual machine

[David Woodhouse <dwmw2@infradead.org>]

On Tue, 2010-06-15 at 16:10 +0200, Joerg Roedel wrote:
> On Mon, Jun 14, 2010 at 07:19:17PM -0400, David Woodhouse wrote:
> > Why not just jump straight to the 'DMA proxy' device, and use that
> > _only_?
> 
> Not sure about Intel chipsets, but on AMD chipset a legacy device can be
> seen by the IOMMU with both device-ids, its own and the bridge device.
> So the domain needs to be configured for both device-ids in the iommu
> driver.

'can be seen with both' sounds odd to me... you mean that depending on
the phase of the moon, it may show up with one or the other on the
_same_ hardware? Or is your IOMMU sufficiently different that you
actually mean both ids are present at the same time for mapping
purposes?

Or do you just mean that you can't always tell which it'll be, so if
there's a _possibility_ that an upstream bridge will act as a proxy, you
map both of them so that you don't have to worry about false positives
in your "is there a proxy?" algorithm?

That approach may make a lot of sense -- but still I don't see why we'd
set up the mapping for _every_ PCI bridge from the device up to the
suspected proxy... unless we're _really_ unsure about where the
transactions will appear to come from, perhaps?

Have you encountered these Ricoh multi-function devices and observed
them doing DMA transactions from function zero regardless of which
function is actually responsible for it:
03:00.0 SD Host controller: Ricoh Co Ltd Device e822 (rev 03)
03:00.4 FireWire (IEEE 1394): Ricoh Co Ltd Device e832 (rev 03)

Do we need to share a 'quirks' infrastructure for handling such devices?

-- 
dwmw2