From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SF4Bw-0002xM-MS for qemu-devel@nongnu.org; Tue, 03 Apr 2012 09:54:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SF4Bl-0007hU-Go for qemu-devel@nongnu.org; Tue, 03 Apr 2012 09:54:36 -0400 Received: from smtp.citrix.com ([66.165.176.89]:17271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SF4Bl-0007h4-77 for qemu-devel@nongnu.org; Tue, 03 Apr 2012 09:54:25 -0400 Message-ID: <4F7B0122.9090602@citrix.com> Date: Tue, 3 Apr 2012 14:54:42 +0100 From: Julien Grall MIME-Version: 1.0 References: <20345.56773.8058.87028@mariner.uk.xensource.com> <20346.64407.174158.890551@mariner.uk.xensource.com> In-Reply-To: <20346.64407.174158.890551@mariner.uk.xensource.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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: Ian Jackson Cc: Julian Pidancet , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Stefano Stabellini On 04/03/2012 02:31 PM, Ian Jackson wrote: > Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"): > >> On Mon, 2 Apr 2012, Ian Jackson wrote: >> >>> I don't think this is really a suitable interface. The PCI space in >>> the guest is controlled by the device models(s) and the user should >>> surely specify which devices should be provided by which dms, in terms >>> of devices not in terms of PCI space. >>> >> >> Julien added a name parameter to select the device, maybe we need >> something clearer? >> Specifying the PCI address is important, because we have to make sure >> the PCI addresses of the devices remain the same in a given VM across >> multiple boots. >> > Are the PCI addresses not assigned in a deterministic fashion by code > in qemu-dm, in this case in the qemu-dm which is emulating the pci > bridge ? If not then that needs to be fixed, surely ? > Indeed but each QEMU emulate a subset of the hardware. So how QEMU can know the available PCI addresses ? I think that toolstack must allocate the BDF, otherwise we need to have communication between each qemu-dm. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models Date: Tue, 3 Apr 2012 14:54:42 +0100 Message-ID: <4F7B0122.9090602@citrix.com> References: <20345.56773.8058.87028@mariner.uk.xensource.com> <20346.64407.174158.890551@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20346.64407.174158.890551@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: Julian Pidancet , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 04/03/2012 02:31 PM, Ian Jackson wrote: > Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the new option device_models"): > >> On Mon, 2 Apr 2012, Ian Jackson wrote: >> >>> I don't think this is really a suitable interface. The PCI space in >>> the guest is controlled by the device models(s) and the user should >>> surely specify which devices should be provided by which dms, in terms >>> of devices not in terms of PCI space. >>> >> >> Julien added a name parameter to select the device, maybe we need >> something clearer? >> Specifying the PCI address is important, because we have to make sure >> the PCI addresses of the devices remain the same in a given VM across >> multiple boots. >> > Are the PCI addresses not assigned in a deterministic fashion by code > in qemu-dm, in this case in the qemu-dm which is emulating the pci > bridge ? If not then that needs to be fixed, surely ? > Indeed but each QEMU emulate a subset of the hardware. So how QEMU can know the available PCI addresses ? I think that toolstack must allocate the BDF, otherwise we need to have communication between each qemu-dm.