On Wed, Oct 20, 2010 at 08:58:38AM -0600, Alex Williamson wrote: > On Wed, 2010-10-20 at 15:43 +0200, Michael S. Tsirkin wrote: > > On Wed, Oct 20, 2010 at 12:59:42PM +0200, Avi Kivity wrote: > > > How far away is vfio? If it's merged soon, we might avoid making > > > changes to the old assigned device infrastructure and instead update > > > vfio. > > > > Hard to be sure, hopefully 2.6.38 material. > > > > Some issues off the top of my head are > > - readonly/virtualized table correctness > > hopefully will start converging now that > > we are switching to standard registers from pci_regs.h > > - work out some capability negotiation mechanism so userspace/kernel > > can detect bug fixes/missing features and recover or fail gracefully > > - with multiple assigned devices in a guest: > > I don't think we have figured out how do they share an iommu context > > A single UIOMMU fd can be used for multiple devices. The code I wrote > supports this, but it's really only meant to support a uiommufd passed > via the command line for libvirt usage. Since libvirt doesn't yet > support vfio, it's never been tested. I think there was some issue that programming was done through vfio fd and got lost if you try to hot unplug device which programmed it. Maybe I'm wrong ... > > - maybe: reset handling (flr support) - need to look a it > > I'd add that for the qemu vfio driver, we need to work out the KVM > interrupt optimizations, otherwise we suffer extra latency vs current > code. You see this in some benchmark? > > > > > On the other hand, changes to the old infrastructure are much > > > more amenable to backporting for long term support distro kernels, > > > so we may need to actively develop both for a while. > > Yep, I think we'll need to continue development and probably maintain > them both for a while. > > Alex -- 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
