From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB8Pa-0002kU-Mm for qemu-devel@nongnu.org; Tue, 04 Oct 2011 13:04:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RB8PZ-0002K7-Iy for qemu-devel@nongnu.org; Tue, 04 Oct 2011 13:04:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55208) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB8PZ-0002K2-7Q for qemu-devel@nongnu.org; Tue, 04 Oct 2011 13:04:09 -0400 Message-ID: <4E8B3C7F.4020300@redhat.com> Date: Tue, 04 Oct 2011 19:03:59 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1317739882-4809-1-git-send-email-anthony.perard@citrix.com> <4E8B1F0D.4080203@redhat.com> <4E8B1FBC.2080904@codemonkey.ws> In-Reply-To: <4E8B1FBC.2080904@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] [PATCH RFC V1 00/11] Xen PCI Passthrough List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Anthony PERARD , Alex Williamson , Xen Devel , QEMU-devel , Stefano Stabellini 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Xen-devel] [PATCH RFC V1 00/11] Xen PCI Passthrough Date: Tue, 04 Oct 2011 19:03:59 +0200 Message-ID: <4E8B3C7F.4020300@redhat.com> References: <1317739882-4809-1-git-send-email-anthony.perard@citrix.com> <4E8B1F0D.4080203@redhat.com> <4E8B1FBC.2080904@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4E8B1FBC.2080904@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Anthony Liguori Cc: Anthony PERARD , Alex Williamson , Xen Devel , QEMU-devel , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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