From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SB4yP-00054v-EZ for qemu-devel@nongnu.org; Fri, 23 Mar 2012 09:56:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SB4yJ-0002zV-I0 for qemu-devel@nongnu.org; Fri, 23 Mar 2012 09:56:09 -0400 Received: from smtp.ctxuk.citrix.com ([62.200.22.115]:13728 helo=SMTP.EU.CITRIX.COM) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SB4yJ-0002yc-Bs for qemu-devel@nongnu.org; Fri, 23 Mar 2012 09:56:03 -0400 Message-ID: <1332510959.30916.50.camel@zakaz.uk.xensource.com> From: Ian Campbell Date: Fri, 23 Mar 2012 13:55:59 +0000 In-Reply-To: <4F6C7554.5080706@citrix.com> References: <1332503243.30916.38.camel@zakaz.uk.xensource.com> <4F6C7554.5080706@citrix.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Subject: Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 12/15] xl: Add interface to handle multiple device models List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Julien Grall Cc: Julian Pidancet , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Stefano Stabellini On Fri, 2012-03-23 at 13:06 +0000, Julien Grall wrote: > >> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl > >> index 413a1a6..7e48817 100644 > >> --- a/tools/libxl/libxl_types.idl > >> +++ b/tools/libxl/libxl_types.idl > >> @@ -37,6 +37,7 @@ libxl_domain_type = Enumeration("domain_type", [ > >> libxl_device_model_version = Enumeration("device_model_version", [ > >> (1, "QEMU_XEN_TRADITIONAL"), # Historical qemu-xen device model (qemu-dm) > >> (2, "QEMU_XEN"), # Upstream based qemu-xen device model > >> + (3, "MULTIPLE_QEMU_XEN"), # Handle multiple dm > >> > > Isn't this implicit in the provision or otherwise of num_dms? > > > Sorry but I don't understand the question. What I mean is can't you tell that the user wants multiple qemus from the fact that domain_config.num_dms is non-zero (or >1, whichever it is)? > > What are name and path? I guess path is something to do with xenstore > > but isn't that also internal to the libxl<->dm interface not something > > the caller of libxl need be aware of? > > > The path is the binary path Are these supposed to supersede libxl_domain_build_info.device_model ? > and the name is just a string append to the log filename. This could be internal to libxl I expect. > > I'm not sure what syntax "pcis", "mmios" and "pios" are going to have > > but I expect that this would be better represent as actual > > datastructures rather than encoding it as a string. > > > > How are toolstack supposed to know the values for e.g. pcis? > > > For the moment pcis are describe as bdf for instance: 00:01.1 > and mmios/pios as range (0x10-0x20 or just 0x19). And how does the toolstack know what values to use? How does it decide that BDF 00:01.1 is something it wants to move into a different DM? > > All in all this seems like a very raw/low-level interface. Can libxl not > > expose something a bit more meaningful to toolstack authors? For example > > if we consider emulated disk controllers then perhaps the options are > > * Handled by the "primary" dm > > * Handled by a single disaggregated dm > > * Handled by multiple disaggregated dm's (one per disk controller) > > Similarly for other classes or emulated device. Or maybe this should be > > a flag on those actual devices (e.g. in libxl_device_FOO)? > > > > I have not really ideas about that. The first solution that comes > in my mind is to bind each device with the device model name. > > But in this case, we need to modify QEMU to launch only a subset > of hardware and find a way to said which QEMU will emulate the > "basic" hardware (keyboard, mouse, piix, ...). > Moreover, who will allocate the bdf ? The toolstack ? I don't know. It's (currently) not the toolstack AFAIK, I guess it is either the lower level libraries (libxl, libxc) or the device model itself. I think this needs figuring out before we can decide what a sensible libxl interface for for describing which device is emulated by which dm looks like. What I want to avoid is the situation where there is something deep in the bowels of Xen which defines (or even hardcodes) the property that BDF X:Y.Z corresponds the some device or other and then require that the upper level tool stack (or, worse, the user) then has to encode that magic knowledge as a string in the configuration. > >> + > >> # Instances of libxl_file_reference contained in this struct which > >> # have been mapped (with libxl_file_reference_map) will be unmapped > >> # by libxl_domain_build/restore. If either of these are never called > >> @@ -289,6 +299,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ > >> ("usbdevice", string), > >> ("soundhw", string), > >> ("xen_platform_pci", libxl_defbool), > >> + ("max_servers", integer), > >> > > As a toolstack author how do I decide what number to use here? > > > The max_servers variables is used to compute the additionnal special pages. > So the max_servers indicates the maximum servers that we want to spawn. We already know this from num_dms, don't we? Ian. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [XEN][RFC PATCH 12/15] xl: Add interface to handle multiple device models Date: Fri, 23 Mar 2012 13:55:59 +0000 Message-ID: <1332510959.30916.50.camel@zakaz.uk.xensource.com> References: <1332503243.30916.38.camel@zakaz.uk.xensource.com> <4F6C7554.5080706@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F6C7554.5080706@citrix.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: Julien Grall Cc: Julian Pidancet , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Fri, 2012-03-23 at 13:06 +0000, Julien Grall wrote: > >> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl > >> index 413a1a6..7e48817 100644 > >> --- a/tools/libxl/libxl_types.idl > >> +++ b/tools/libxl/libxl_types.idl > >> @@ -37,6 +37,7 @@ libxl_domain_type = Enumeration("domain_type", [ > >> libxl_device_model_version = Enumeration("device_model_version", [ > >> (1, "QEMU_XEN_TRADITIONAL"), # Historical qemu-xen device model (qemu-dm) > >> (2, "QEMU_XEN"), # Upstream based qemu-xen device model > >> + (3, "MULTIPLE_QEMU_XEN"), # Handle multiple dm > >> > > Isn't this implicit in the provision or otherwise of num_dms? > > > Sorry but I don't understand the question. What I mean is can't you tell that the user wants multiple qemus from the fact that domain_config.num_dms is non-zero (or >1, whichever it is)? > > What are name and path? I guess path is something to do with xenstore > > but isn't that also internal to the libxl<->dm interface not something > > the caller of libxl need be aware of? > > > The path is the binary path Are these supposed to supersede libxl_domain_build_info.device_model ? > and the name is just a string append to the log filename. This could be internal to libxl I expect. > > I'm not sure what syntax "pcis", "mmios" and "pios" are going to have > > but I expect that this would be better represent as actual > > datastructures rather than encoding it as a string. > > > > How are toolstack supposed to know the values for e.g. pcis? > > > For the moment pcis are describe as bdf for instance: 00:01.1 > and mmios/pios as range (0x10-0x20 or just 0x19). And how does the toolstack know what values to use? How does it decide that BDF 00:01.1 is something it wants to move into a different DM? > > All in all this seems like a very raw/low-level interface. Can libxl not > > expose something a bit more meaningful to toolstack authors? For example > > if we consider emulated disk controllers then perhaps the options are > > * Handled by the "primary" dm > > * Handled by a single disaggregated dm > > * Handled by multiple disaggregated dm's (one per disk controller) > > Similarly for other classes or emulated device. Or maybe this should be > > a flag on those actual devices (e.g. in libxl_device_FOO)? > > > > I have not really ideas about that. The first solution that comes > in my mind is to bind each device with the device model name. > > But in this case, we need to modify QEMU to launch only a subset > of hardware and find a way to said which QEMU will emulate the > "basic" hardware (keyboard, mouse, piix, ...). > Moreover, who will allocate the bdf ? The toolstack ? I don't know. It's (currently) not the toolstack AFAIK, I guess it is either the lower level libraries (libxl, libxc) or the device model itself. I think this needs figuring out before we can decide what a sensible libxl interface for for describing which device is emulated by which dm looks like. What I want to avoid is the situation where there is something deep in the bowels of Xen which defines (or even hardcodes) the property that BDF X:Y.Z corresponds the some device or other and then require that the upper level tool stack (or, worse, the user) then has to encode that magic knowledge as a string in the configuration. > >> + > >> # Instances of libxl_file_reference contained in this struct which > >> # have been mapped (with libxl_file_reference_map) will be unmapped > >> # by libxl_domain_build/restore. If either of these are never called > >> @@ -289,6 +299,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ > >> ("usbdevice", string), > >> ("soundhw", string), > >> ("xen_platform_pci", libxl_defbool), > >> + ("max_servers", integer), > >> > > As a toolstack author how do I decide what number to use here? > > > The max_servers variables is used to compute the additionnal special pages. > So the max_servers indicates the maximum servers that we want to spawn. We already know this from num_dms, don't we? Ian.