Re: [Qemu-devel] [Xen-devel] [PATCH RFC V1 00/11] Xen PCI Passthrough

[Alex Williamson <alex.williamson@xxxxxxxxxx>]

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,

Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel