From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB9ft-0005gB-D8 for qemu-devel@nongnu.org; Tue, 04 Oct 2011 14:25:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RB9fn-0007iP-E6 for qemu-devel@nongnu.org; Tue, 04 Oct 2011 14:25:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3186) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB9fn-0007iK-2z for qemu-devel@nongnu.org; Tue, 04 Oct 2011 14:24:59 -0400 Message-ID: <4E8B4F70.2030009@redhat.com> Date: Tue, 04 Oct 2011 20:24:48 +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> <4E8B3C7F.4020300@redhat.com> In-Reply-To: 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: Stefano Stabellini Cc: Anthony Perard , Alex Williamson , Xen Devel , QEMU-devel 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 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 20:24:48 +0200 Message-ID: <4E8B4F70.2030009@redhat.com> 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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: Stefano Stabellini Cc: Anthony Perard , Alex Williamson , Xen Devel , QEMU-devel List-Id: xen-devel@lists.xenproject.org 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