Xen devel - Jul 2010 - [PATCH 0/3] libxl stubdom API cleanup

This patch serie cleans the stubdom API, and remove some of the policy embedded
in libxl. libxl users are expected to start explicitely a stubdomain instead of
relying
on a magic value in devicemodel_create.

Vincent Hanquez (3):
  move stubdom make into a proper function
  let the user of libxenlight choose explicitely if it want to start a
    stubdom or not.
  stubdom_create returns stubdomain domid so that unpause is done by
    the user of libxenlight.

 tools/libxl/libxl.c      |   99 ++++++++++++++++++++++++++--------------------
 tools/libxl/libxl.h      |   25 +++++++++++-
 tools/libxl/xl_cmdimpl.c |   14 ++++++-
 3 files changed, 92 insertions(+), 46 deletions(-)


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

Signed-off-by: Vincent Hanquez <vincent.hanquez@eu.citrix.com>
---
 tools/libxl/libxl.c |   72 ++++++++++++++++++++++++++++++++------------------
 tools/libxl/libxl.h |   10 +++++++
 2 files changed, 56 insertions(+), 26 deletions(-)



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

the same mechanism of choosing stubdomain or not, depending on the qemu-dm
filename that was embedded in the libxenlight is moved to xl so that nothing
change. also expose more functions that the caller is expected to used now.

Signed-off-by: Vincent Hanquez <vincent.hanquez@eu.citrix.com>
---
 tools/libxl/libxl.c      |   30 +++++++++++-------------------
 tools/libxl/libxl.h      |   15 ++++++++++++++-
 tools/libxl/xl_cmdimpl.c |   12 ++++++++++--
 3 files changed, 35 insertions(+), 22 deletions(-)



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

Signed-off-by: Vincent Hanquez <vincent.hanquez@eu.citrix.com>
---
 tools/libxl/libxl.c      |    7 ++++---
 tools/libxl/libxl.h      |    2 +-
 tools/libxl/xl_cmdimpl.c |    4 +++-
 3 files changed, 8 insertions(+), 5 deletions(-)



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

On Wed, 7 Jul 2010, Vincent Hanquez wrote:
> This patch serie cleans the stubdom API, and remove some of the policy
embedded
> in libxl. libxl users are expected to start explicitely a stubdomain
instead of relying
> on a magic value in devicemodel_create.
> 
> Vincent Hanquez (3):
>   move stubdom make into a proper function
>   let the user of libxenlight choose explicitely if it want to start a
>     stubdom or not.
>   stubdom_create returns stubdomain domid so that unpause is done by
>     the user of libxenlight.
> 
I though we wanted to make stubdoms transparent to libxenlight users,
why do you want to expose them now?


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

On 07/07/10 17:53, Stefano Stabellini wrote:
> I though we wanted to make stubdoms transparent to libxenlight users,
> why do you want to expose them now?
>    
 From the users yes, from the libxenlight users (aka developers) no.
It''s also a good way to get the policy out of libxenlight. For example
the
32mb value which might or might not change in future.

-- 
Vincent


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

On Thu, 8 Jul 2010, Vincent Hanquez wrote:
> On 07/07/10 17:53, Stefano Stabellini wrote:
> > I though we wanted to make stubdoms transparent to libxenlight users,
> > why do you want to expose them now?
> >    
>  From the users yes, from the libxenlight users (aka developers) no.
> It''s also a good way to get the policy out of libxenlight. For
example the
> 32mb value which might or might not change in future.
 
Fair enough.
I ack the whole series then.


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

On Thu, 2010-07-08 at 15:03 +0100, Stefano Stabellini
wrote:
> On Thu, 8 Jul 2010, Vincent Hanquez wrote:
> > On 07/07/10 17:53, Stefano Stabellini wrote:
> > > I though we wanted to make stubdoms transparent to libxenlight
users,
> > > why do you want to expose them now?
> > >    
> >  From the users yes, from the libxenlight users (aka developers) no.
> > It''s also a good way to get the policy out of libxenlight.
For example the
> > 32mb value which might or might not change in future.
>  
> Fair enough.
> I ack the whole series then.
Is it necessary to pull the mechanism out along with the policy though? 

Could the libxl user not specify one of nostubdom, stubdom or
libxlchooses (the default?) and let the internals of libxl take care of
actually starting it etc?

Ian.



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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 0/3] libxl stubdom API
cleanup"):
> Could the libxl user not specify one of nostubdom, stubdom or
> libxlchooses (the default?) and let the internals of libxl take care of
> actually starting it etc?
Quite so.

Ian.

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

On 08/07/10 15:18, Ian Campbell wrote:
> On Thu, 2010-07-08 at 15:03 +0100, Stefano Stabellini wrote:
>> On Thu, 8 Jul 2010, Vincent Hanquez wrote:
>>> On 07/07/10 17:53, Stefano Stabellini wrote:
>>>> I though we wanted to make stubdoms transparent to libxenlight
users,
>>>> why do you want to expose them now?
>>>>
>>>    From the users yes, from the libxenlight users (aka developers)
no.
>>> It''s also a good way to get the policy out of libxenlight.
For example the
>>> 32mb value which might or might not change in future.
>>
>> Fair enough.
>> I ack the whole series then.
>
> Is it necessary to pull the mechanism out along with the policy though?
Necessary is quite a strong word.
> Could the libxl user not specify one of nostubdom, stubdom or
> libxlchooses (the default?) and let the internals of libxl take care of
> actually starting it etc?
Starting a stubdom or not, imply 2 very different side effects (e.g. 
memory wise). Separating the API give better error reporting, more room 
for action (e.g. creating a domain without stubdom if you don''t have 
those N mb to spare), and it also simplify the ocaml bindings not having 
to encode complex semantics on the ocaml side.

-- 
Vincent

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

On Thu, 2010-07-08 at 18:18 +0100, Vincent Hanquez
wrote:
> On 08/07/10 15:18, Ian Campbell wrote:
> > On Thu, 2010-07-08 at 15:03 +0100, Stefano Stabellini wrote:
> >> On Thu, 8 Jul 2010, Vincent Hanquez wrote:
> >>> On 07/07/10 17:53, Stefano Stabellini wrote:
> >>>> I though we wanted to make stubdoms transparent to
libxenlight users,
> >>>> why do you want to expose them now?
> >>>>
> >>>    From the users yes, from the libxenlight users (aka
developers) no.
> >>> It''s also a good way to get the policy out of
libxenlight. For example the
> >>> 32mb value which might or might not change in future.
> >>
> >> Fair enough.
> >> I ack the whole series then.
> >
> > Is it necessary to pull the mechanism out along with the policy
though?
> 
> Necessary is quite a strong word.
> 
> > Could the libxl user not specify one of nostubdom, stubdom or
> > libxlchooses (the default?) and let the internals of libxl take care
of
> > actually starting it etc?
> 
> Starting a stubdom or not, imply 2 very different side effects (e.g. 
> memory wise). Separating the API give better error reporting, more room 
> for action (e.g. creating a domain without stubdom if you don''t
have
> those N mb to spare), and it also simplify the ocaml bindings not having 
> to encode complex semantics on the ocaml side.
Fair enough.




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

At 15:18 +0100 on 08 Jul (1278602309), Ian Campbell
wrote:
> On Thu, 2010-07-08 at 15:03 +0100, Stefano Stabellini wrote:
> > On Thu, 8 Jul 2010, Vincent Hanquez wrote:
> > > On 07/07/10 17:53, Stefano Stabellini wrote:
> > > > I though we wanted to make stubdoms transparent to
libxenlight users,
> > > > why do you want to expose them now?
> > > >    
> > >  From the users yes, from the libxenlight users (aka developers)
no.
> > > It''s also a good way to get the policy out of
libxenlight. For example the
> > > 32mb value which might or might not change in future.
> >  
> > Fair enough.
> > I ack the whole series then.
> 
> Is it necessary to pull the mechanism out along with the policy though? 
Or, if we''re taking some mechanism out, couldn''t we take _all_
the
mechanism out?  The idea of a stub domain doesn''t seem like one that
libxl necessarily needs to know about.

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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

On 09/07/10 09:17, Tim Deegan wrote:
>> Is it necessary to pull the mechanism out along with the policy though?
>>      
> Or, if we''re taking some mechanism out, couldn''t we take
_all_ the
> mechanism out?
Which one do you have in minds ?
> The idea of a stub domain doesn''t seem like one that
> libxl necessarily needs to know about.
>    
yes, indeed. the stubdom create could move as a xl helper.
On the ocaml side reimplementing stubdom create is a trivial composition 
of smaller libxl function (create/build/add devs) which are already bound.

-- 
Vincent

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

At 11:44 +0100 on 09 Jul (1278675850), Vincent Hanquez
wrote:
> On 09/07/10 09:17, Tim Deegan wrote:
> >> Is it necessary to pull the mechanism out along with the policy
though?
> >>      
> > Or, if we''re taking some mechanism out, couldn''t we
take _all_ the
> > mechanism out?
> 
> Which one do you have in minds ?
It looks like your patch leaves some "create a stubdom" functions in
the
libxl API.  I''d have thought libxl should either handle stubdoms
entirely or not at all.  (Unless stubdom creation needs some low-level
grunge that will uglify the libxl API if it''s exposed that far up - I
can''t think of any except PRIV_FOR though).
> > The idea of a stub domain doesn''t seem like one that
> > libxl necessarily needs to know about.
> >    
> yes, indeed. the stubdom create could move as a xl helper.
> On the ocaml side reimplementing stubdom create is a trivial composition 
> of smaller libxl function (create/build/add devs) which are already bound.
That sounds cleaner to me.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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

On Fri, 9 Jul 2010, Tim Deegan wrote:
> At 11:44 +0100 on 09 Jul (1278675850), Vincent Hanquez wrote:
> > On 09/07/10 09:17, Tim Deegan wrote:
> > >> Is it necessary to pull the mechanism out along with the
policy though?
> > >>      
> > > Or, if we''re taking some mechanism out,
couldn''t we take _all_ the
> > > mechanism out?
> > 
> > Which one do you have in minds ?
> 
> It looks like your patch leaves some "create a stubdom" functions
in the
> libxl API.  I''d have thought libxl should either handle stubdoms
> entirely or not at all.  (Unless stubdom creation needs some low-level
> grunge that will uglify the libxl API if it''s exposed that far up
- I
> can''t think of any except PRIV_FOR though).
> 
> > > The idea of a stub domain doesn''t seem like one that
> > > libxl necessarily needs to know about.
> > >    
> > yes, indeed. the stubdom create could move as a xl helper.
> > On the ocaml side reimplementing stubdom create is a trivial
composition
> > of smaller libxl function (create/build/add devs) which are already
bound.
> 
> That sounds cleaner to me.
> 
I am not so sure about this: a stubdom is not just a normal PV guest, it
also needs some special plumbings in xenstore.
By design libxl clients are not required to know about xenstore,
therefore we cannot have stubdoms entirely built by libxl clients.
I think that working around this would be worse than Vincent''s current
patch series.


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

On 09/07/10 11:51, Tim Deegan wrote:
> At 11:44 +0100 on 09 Jul (1278675850), Vincent Hanquez wrote:
>    
>> On 09/07/10 09:17, Tim Deegan wrote:
>>      
>>>> Is it necessary to pull the mechanism out along with the policy
though?
>>>>
>>>>          
>>> Or, if we''re taking some mechanism out, couldn''t
we take _all_ the
>>> mechanism out?
>>>        
>> Which one do you have in minds ?
>>      
> It looks like your patch leaves some "create a stubdom" functions
in the
> libxl API.  I''d have thought libxl should either handle stubdoms
> entirely or not at all.  (Unless stubdom creation needs some low-level
> grunge that will uglify the libxl API if it''s exposed that far up
- I
> can''t think of any except PRIV_FOR though).
>    
I think that either is fine from my point of view; as long as I don''t 
have to capture two very different semantics (starting a program | 
starting a domain) in one call.

-- 
Vincent

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

At 11:59 +0100 on 09 Jul (1278676763), Stefano Stabellini
wrote:
> I am not so sure about this: a stubdom is not just a normal PV guest, it
> also needs some special plumbings in xenstore.
> By design libxl clients are not required to know about xenstore,
> therefore we cannot have stubdoms entirely built by libxl clients.
> I think that working around this would be worse than Vincent''s
current
> patch series.
Fair enough.

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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

Vincent Hanquez writes ("Re: [Xen-devel] [PATCH 0/3] libxl stubdom API
cleanup"):
> I think that either is fine from my point of view; as long as I
don''t
> have to capture two very different semantics (starting a program | 
> starting a domain) in one call.
I still disagree.  I think it would be better to hide this distinction
as much as possible.

Your key motive seems to be some problem with the ocaml bindings.
Perhaps you could explain that in more detail ?

Ian.

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

On Fri, 9 Jul 2010, Ian Jackson wrote:
> Vincent Hanquez writes ("Re: [Xen-devel] [PATCH 0/3] libxl stubdom API
cleanup"):
> > I think that either is fine from my point of view; as long as I
don''t
> > have to capture two very different semantics (starting a program | 
> > starting a domain) in one call.
> 
> I still disagree.  I think it would be better to hide this distinction
> as much as possible.
> 
> Your key motive seems to be some problem with the ocaml bindings.
> Perhaps you could explain that in more detail ?
 
I think Vincent wanted a different API to make memory accounting easier.

What about extending the current create_device_model API with a
more explicit stubdom flag, and a way to return the stubdom domid to the
caller?

Also the caller should be able to know in advance the amount of memory
used for the stubdom: another libxl function could be added for that
purpose.

Would that interface be flexible enough for you?

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

On 09/07/10 18:04, Ian Jackson wrote:
> Vincent Hanquez writes ("Re: [Xen-devel] [PATCH 0/3] libxl stubdom API
cleanup"):
>> I think that either is fine from my point of view; as long as I
don''t
>> have to capture two very different semantics (starting a program |
>> starting a domain) in one call.
>
> I still disagree.  I think it would be better to hide this distinction
> as much as possible.
>
> Your key motive seems to be some problem with the ocaml bindings.
> Perhaps you could explain that in more detail ?
This has nothing to do with the ocaml bindings, but this has to do with 
who is using those bindings (i.e. a fully featured toolstack).

-- 
Vincent

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

--text follows this line--
Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 0/3] libxl stubdom API
cleanup"):
> I think Vincent wanted a different API to make memory accounting easier.
Right.
> What about extending the current create_device_model API with a
> more explicit stubdom flag, and a way to return the stubdom domid to the
> caller?
> 
> Also the caller should be able to know in advance the amount of memory
> used for the stubdom: another libxl function could be added for that
> purpose.
> 
> Would that interface be flexible enough for you?
That would address my concerns.

Ian.

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