On Tue, 4 Oct 2011, Alex Williamson wrote: > On Tue, 2011-10-04 at 16:05 +0100, Stefano Stabellini wrote: > > On Tue, 4 Oct 2011, Anthony Liguori wrote: > > > On 10/04/2011 09:58 AM, Avi Kivity wrote: > > > > On 10/04/2011 04:51 PM, Anthony PERARD wrote: > > > >> Hi all, > > > >> > > > >> This patch series introduce the PCI passthrough for Xen. > > > >> > > > >> First, we have HostPCIDevice that help to access one PCI device of the > > > >> host. > > > >> > > > >> Then, there are several additions in the QEMU code. One is > > > >> qemu_run_one_timer > > > >> to run a specific timer. It is used by PCI passthrough to run a timer > > > >> about > > > >> power management. Another is pci_check_bar_overlap. > > > >> > > > >> There are also several change in pci_ids and pci_regs. > > > >> > > > >> Last part, but not least, the PCI passthrough device himself. Cut in 3 > > > >> parts > > > >> (or file), there is one to take care of the initialisation of a > > > >> passthrough > > > >> device. The second one handle everything about the config address > > > >> space, there > > > >> are specifics functions for every config register. The third one is to > > > >> handle > > > >> MSI. > > > >> > > > >> I'm still working on setting a PCI passthrough device through QMP from > > > >> libxl > > > >> (xen tool stack). It is just a call to device_add, with the driver > > > >> parametter > > > >> hostaddr="0000:00:1b.0". > > > >> > > > >> There is some minor things missing: > > > >> - copyright header > > > >> - PCI IO space multiplexer > > > >> > > > >> > > > > > > > > We also have pci passthrough in qemu-kvm (I think based on the same > > > > Neocleus > > > > code). Rather than having two pci assignment implementations, I think > > > > we should > > > > have just one, with the differences (programming the hypervisor) > > > > abstracted at > > > > that level. > > > > > > I agree in principle but how close is qemu-kvm pci passthrough to a > > > mergable > > > state? Would it make sense to merge the Xen code first and then abstract > > > it? > > > > I think it should be fairly easy to abstract the current xen code: just > > a matter of providing memory, ioport and interrupt mapping functions. > > I thought we were potentially looking at vfio as a convergence point. > I'm still a bit off from having a vfio re-write ready to submit, but is > this still a possibility? Thanks,
As I said at KVM Forum 2011, I am OK with vfio: it is a nice thing to have in the long term. However having seen how much time it took to make this code work reliably, I think is going to take some time before we have a stable vfio implementation. Considering that we have just introduced upstream qemu to xen-unstable, I would like to reach feature parity with the old qemu-xen sooner rather than later, so that we can kill the qemu-xen fork once and for all. In order to reach feature parity we need PCI passthrough. Once that is done, we could gradually modify this code to introduce vfio support, throwing away what is not necessary and keeping what can be reused. If you are interested, we can easily make this code work for KVM too, otherwise we can keep it Xen specific and wait for vfio to be ready.
