Re: [Qemu-devel] [RFC PATCH] vfio: VFIO PCI driver for Qemu

[Alex Williamson <alex.williamson@redhat.com>]

On Thu, 2012-07-26 at 23:23 +0200, Andreas Hartmann wrote:
> Alex Williamson wrote:
> 
> [I removed qemu-devel because I'm not registered there]
> 
> > On Thu, 2012-07-26 at 19:40 +0300, Avi Kivity wrote:
> >> On 07/26/2012 07:33 PM, Alex Williamson wrote:
> >>>>
> >>>> In the common case, on x86 (but I'm repeating myself), the iommu group
> >>>> includes just one device, yes?  Could we make pci-stub an alias for the
> >>>> corresponding vfio steps?
> >>>
> >>> PCI bridges masking devices is not as uncommon as you'd like, that's
> >>> exactly why Andreas is using VFIO instead of KVM assignment.  
> >>
> >> Well, we are using it in production for quite a while with few such reports.
> >
> > In the enterprise space, sure.  In the hobbiest/power user space, I
> > suspect users are too often finding that it doesn't work and move on to
> > something else.  Maybe we'll know if it's working better if we get more
> > complaints about random oddball devices not working because people are
> > actually able to get far enough to try it.
> 
> I think it's the complete 900-chipset series of AMD (990FX, 990X [the
> one I'm using] and 970 - Socket AM3+), which provides the desktop user
> with payable IOMMU support (e.g.
> http://www.gigabyte.us/products/list.aspx?s=42&jid=7&p=2&v=26 ). I
> already read from other users having the same problem.

Right, the non-enterprise-y thing you're trying to do though is assign a
legacy PCI device, which on this chipset sits behind a P2P bridge and
amd-iommu pre-assigns domains whereas intel-iommu does it dynamically,
making them "just work".  Enterprise customers are assigning high
performance PCIe devices or even virtual functions, that typically
aren't masked by bridges.  We like to think of legacy PCI assignment as
a migration tool for people wanting to consolidate old hardware, but due
to things like this, it doesn't always work.  Thanks,

Alex