WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH RFC V1 00/11] Xen PCI Passthrough
From: Avi Kivity <avi@xxxxxxxxxx>
Date: Tue, 04 Oct 2011 19:03:59 +0200
Cc: Anthony PERARD <anthony.perard@xxxxxxxxxx>, Alex Williamson <alex.williamson@xxxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, QEMU-devel <qemu-devel@xxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 04 Oct 2011 10:10:32 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E8B1FBC.2080904@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1317739882-4809-1-git-send-email-anthony.perard@xxxxxxxxxx> <4E8B1F0D.4080203@xxxxxxxxxx> <4E8B1FBC.2080904@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2
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.

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.

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


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