David Woodhouse wrote:
On Thu, 2010-06-17 at 11:35 +0800, Weidong Han wrote:
David Woodhouse wrote:
So why do we bother setting up a context in the IOMMU for the device
itself, when no DMA will ever appear to come from this device? And
if the device is behind PCI Express-to-PCI/PCI-X bridge, the source-id
may be the device bdf or the source-id provided by the bridge. so it
needs to map the device itself.
Ah, that makes some sense, and matches what Jörg said about the AMD
IOMMU spec. Thanks.
likewise why do we bother setting up a context for intermediate PCI
bridges?
I'm not sure if the intermediate PCI bridges are necessary. need to
check PCI spec.
FWIW, the AMD IOMMU doesn't do this; it only sets up the mapping for the
original device and for its 'proxy'.
Why not just jump straight to the 'DMA proxy' device, and use that
_only_?
What's the 'DMA proxy' device? is it the upstream pcie-to-pci bridge?
Yes. Or, in the case of a certain buggy Ricoh multi-function device, it
is function zero -- all other functions do their DMA as if it came from
function zero.
This is why I'm looking at whether we need the whole tree-walking thing,
or whether we can just have a single 'proxy' device (or 'alias' as it's
called in the AMD code).
all the device behind a pcie-to-pci bridge must be co-assigned to a
single domain. So it also require users to detach them together.
Do we even _have_ an API for KVM to assign multiple devices at the same
time? Or an API for KVM to _determine_ which devices are behind the same
'proxy'?
No. I think it's better to add some checks in management tool (e.g.
libvirt) to determine if the devices can be assigned or not before
device assignment, such as all devices behind same 'proxy' are
co-assigned (checking command line), and devices can be reset (FLR,
secondary bus reset, D0->D3 etc.) I think libvirt already has these
checks for device assignment.
We could even have a new device hotplugged after the assignment has been
done.
yes, but for these legacy devices, they only can be assigned and
de-assigned at the same time.
Regards,
Weidong
--
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
