From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SF4dp-00038s-2c for qemu-devel@nongnu.org; Tue, 03 Apr 2012 10:23:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SF4df-0007vU-9K for qemu-devel@nongnu.org; Tue, 03 Apr 2012 10:23:24 -0400 Received: from smtp.ctxuk.citrix.com ([62.200.22.115]:55593 helo=SMTP.EU.CITRIX.COM) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SF4df-0007vG-3L for qemu-devel@nongnu.org; Tue, 03 Apr 2012 10:23:15 -0400 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20347.1997.860895.62256@mariner.uk.xensource.com> Date: Tue, 3 Apr 2012 15:23:09 +0100 In-Reply-To: References: <20345.56773.8058.87028@mariner.uk.xensource.com> <20346.64407.174158.890551@mariner.uk.xensource.com> <4F7B0122.9090602@citrix.com> <20347.742.768963.36907@mariner.uk.xensource.com> Subject: Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: "Julien Grall (Intern)" , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Julian Pidancet Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"): > On Tue, 3 Apr 2012, Ian Jackson wrote: > > Currently the bdfs are allocated by the single qemu-dm, right ? Why > > cannot that functionality stay there, with the pci bridge emulation ? > > Because the allocation of most BDFs in QEMU is done ad-hoc in a first > come first served basis. If the first QEMU is not going to emulate these > devices then it is not going to allocate the BDF for them either. Do we want the bdf allocation to be stable when switching between the combined and disaggregated qemu-dms ? If we do then it still needs to be done by that qemu-dm using the same algorithm, presumably with additional ipc. If we don't then it would be ok for the bdfs to be allocated by new code in the toolstack somewhere, eg libxl, but it still shouldn't be up to the user to configure. Ian. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models Date: Tue, 3 Apr 2012 15:23:09 +0100 Message-ID: <20347.1997.860895.62256@mariner.uk.xensource.com> References: <20345.56773.8058.87028@mariner.uk.xensource.com> <20346.64407.174158.890551@mariner.uk.xensource.com> <4F7B0122.9090602@citrix.com> <20347.742.768963.36907@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: "Julien Grall (Intern)" , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Julian Pidancet List-Id: xen-devel@lists.xenproject.org Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"): > On Tue, 3 Apr 2012, Ian Jackson wrote: > > Currently the bdfs are allocated by the single qemu-dm, right ? Why > > cannot that functionality stay there, with the pci bridge emulation ? > > Because the allocation of most BDFs in QEMU is done ad-hoc in a first > come first served basis. If the first QEMU is not going to emulate these > devices then it is not going to allocate the BDF for them either. Do we want the bdf allocation to be stable when switching between the combined and disaggregated qemu-dms ? If we do then it still needs to be done by that qemu-dm using the same algorithm, presumably with additional ipc. If we don't then it would be ok for the bdfs to be allocated by new code in the toolstack somewhere, eg libxl, but it still shouldn't be up to the user to configure. Ian.