From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51627) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB9ac-00021u-GS for qemu-devel@nongnu.org; Tue, 04 Oct 2011 14:19:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RB9aW-0006r9-EQ for qemu-devel@nongnu.org; Tue, 04 Oct 2011 14:19:38 -0400 Received: from smtp.ctxuk.citrix.com ([62.200.22.115]:9842 helo=SMTP.EU.CITRIX.COM) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB9aW-0006r5-91 for qemu-devel@nongnu.org; Tue, 04 Oct 2011 14:19:32 -0400 Date: Tue, 4 Oct 2011 19:19:22 +0100 From: Stefano Stabellini In-Reply-To: <4E8B3C7F.4020300@redhat.com> Message-ID: References: <1317739882-4809-1-git-send-email-anthony.perard@citrix.com> <4E8B1F0D.4080203@redhat.com> <4E8B1FBC.2080904@codemonkey.ws> <4E8B3C7F.4020300@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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: Avi Kivity Cc: Xen Devel , Stefano Stabellini , QEMU-devel , Alex Williamson , Anthony Perard 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. > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [Xen-devel] [PATCH RFC V1 00/11] Xen PCI Passthrough Date: Tue, 4 Oct 2011 19:19:22 +0100 Message-ID: References: <1317739882-4809-1-git-send-email-anthony.perard@citrix.com> <4E8B1F0D.4080203@redhat.com> <4E8B1FBC.2080904@codemonkey.ws> <4E8B3C7F.4020300@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-path: In-Reply-To: <4E8B3C7F.4020300@redhat.com> 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: Avi Kivity Cc: Xen Devel , Stefano Stabellini , QEMU-devel , Alex Williamson , Anthony Perard List-Id: xen-devel@lists.xenproject.org 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. > 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.