WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH,RFC]: Introduce libxl_domain_create()

To: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH,RFC]: Introduce libxl_domain_create()
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Tue, 21 Dec 2010 11:02:58 +0000
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 21 Dec 2010 03:04:58 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1292921096.11246.55.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <1292353212.11246.35.camel@xxxxxxxxxxxxxxxxxxxxxx> <1292576770.32368.11405.camel@xxxxxxxxxxxxxxxxxxxxxx> <1292921096.11246.55.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2010-12-21 at 08:44 +0000, Gianni Tedesco wrote:
> On Fri, 2010-12-17 at 09:06 +0000, Ian Campbell wrote:
> > On Tue, 2010-12-14 at 19:00 +0000, Gianni Tedesco wrote:
> > We probably need IDL support for enumerations and other constants.
> 
> Might be a good idea. We also rely on a few xc constants. In the case of
> the python binding I had been adding them manually. If we did this via
> IDL it'd be an idea to generate type-safety macros for that stuff too.

What sort of macros?

> > > +typedef struct {
> [...]
> > > +} libxl_domain_config;
> > 
> > Should be in IDL so it gets a destructor? Could require adding an Array
> > construct to handle the foo + num_foo style stuff.
> 
> I've thought about that and rejected it because C arrays don't map to
> anything useful in language bindings. It makes sense to me to keep this
> as a builtin and use functions to fill these domain creation related
> structures in for us.

OK

> But then what you get is like two versions of:
>  - libxl_device_add_(nic|block|etc)
> One for a live domain and one for domain creation.
> 
> I have been toying with the idea of using polymorphism (is that what
> it's called?) So that such a function would multiplex to different
> implementations depending on whether this is a live domain or a
> description of a domain for creation. It might need a bit of thinking
> through as how it would be used.
> 
> Not sure what the others think of that?

Proper polymorphism is a bit tricky in C, since you can't have multiple
variations of the same function with different parameters and you simply
end up with multiple different functions -- i.e. back where you started.

The need for a version of libxl_device_add_FOO for the create case is
simply to support automatically extending the array while filing in the
structure etc? I don't see a useful way to have a function which works
like this for both live and in-creation domains.

> > > +static pid_t autoconnect_console(libxl_ctx *ctx, int domid)
> > > +{
> > [...]
> > > +}
> > 
> > I think console connect should be under toolstack control (i.e. stay in
> > xl). exec'ing the xenconsole client is only one way of connecting the
> > console, e.g. xapi might want to launch vncterm instead.
> > 
> > I think libxl_domain_create should take a callback function pointer to
> > connect the console. It's possible that libxl might also provide a
> > convenience function which launches xenconsole which is suitable for use
> > as this callback but ultimately it should be the toolstack's decision
> > what to do here.
> 
> I think you're right. I had just been trying to avoid having a mega
> function with 12 arguments, 6 of them callbacks.

A structure containing the callback functions is the answer there.

> I had the idea that the original domain_create() was very fragile and I
> didn't want to move things around. But on the other hand it seems to me
> that there's no reason to start the console at two different points
> depending on pv or hvm and perhaps I should just try to move the code
> around.

I'm pretty certain Stefano did this deliberately when he introduced
console support for HVM, I don't remember the specific constraint he
found on HVM though. It seems to arise from 22100:fde833c66948 but the
commit message doesn't say why just "it needs to be this way".

> Domains start paused anyway so why can't we just:
> 
>  libxl_domain_create();
>  do_console_stuff();
>  libxl_domain_unpause();

Not quite because for a PV domain we need to do the console before the
bootloader runs (so the user can interact with pygrub) and the
bootloader provides the input to libxl_domain_create().

So for PV it ends up as
        libxl_domain_make() // returns a domid
        do_console_stuff() // launches console client
        libxl_run_bootloader() // potentially interact with console, return 
kernel etc
        libxl_domain_create() // build domain using kernel
        libxl_domain_unpause() // go go go

My guess is that there is some reason you can't create the console for
an HVM guest before libxl_domain_create but I don't specifically know
why, perhaps qemu needs to be running?

In theory at least the do_console_stuff should cause a client to start
and wait for the server end to appear, rather than insist on connecting
immediately and it already behaves that way for PV guests, I don't see
any fundamental reason HVM couldn't be the same.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel