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

[Avi Kivity <avi@redhat.com>]

On 10/04/2011 08:19 PM, Stefano Stabellini wrote:
> On Tue, 4 Oct 2011, Avi Kivity wrote:
> >  On 10/04/2011 05:01 PM, Anthony Liguori wrote:
> >  >>  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?
> >
> >  Merging either implementation and abstracting it would risk regressions
> >  in the other.
>
> Honestly the last time I looked at the kvm passthrough code (admittedly
> a while ago), it looked very similar to the xen passthrough code, so I
> don't think we would risk much merging either one first and then
> abstracting it.

There were 59 commits in the past year to hw/device-assignment.c, so the 
risk is real IMO.

> >  How about merging both, with the ABIs (command line and qmp) tagged as
> >  experimental, and then doing a merge in the same style as
> >  i386+x86_64->x86 or the two kvm implementations in qemu?  We can pick
> >  one implementation as the merge target and port fixes from the other.
>
> I am OK with this too: it is probably more work but it doesn't risk
> loosing any bug fixes.
> If you think that kvm passthrough might have several bug fixes that xen
> passthrough does not have is probably the right way to go.

and the other way round.

-- 
error compiling committee.c: too many arguments to function