future plans for libxl?

future plans for libxl?

[Andre Przywara]

Hi,

what is the current master plan for libxl?
Currently I see that many features already implemented in Python are 
again implemented in libxl (migration, CPU affinity).
Are the Python tools going to be replaced at some point in the future or 
are they just reimplemented to be based upon libxl? For the NUMA guest 
effort I would like to get some ideas on how to handle tool chain 
implementation.
Or is it intended to have both these implementations in parallel (which 
would be kind of unfortunate)?
And how does this affect xend? I see that in opposite to xm some 
functionality of the xl tool works without having xend running (which I 
find very handy, cause I spent countless hours during development to 
just fix some weird xend issues just for calling xm info or xm vcpu-list).
Was there a mail or a document I missed already explaining this?

Thanks!
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448 3567 12
----to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Andrew Bowd; Thomas M. McCoy; Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: future plans for libxl?

[Stefano Stabellini]

On Wed, 14 Apr 2010, Andre Przywara wrote:
> Hi,
> 
> what is the current master plan for libxl?
> Currently I see that many features already implemented in Python are 
> again implemented in libxl (migration, CPU affinity).
> Are the Python tools going to be replaced at some point in the future or 
> are they just reimplemented to be based upon libxl? For the NUMA guest 
> effort I would like to get some ideas on how to handle tool chain 
> implementation.
> Or is it intended to have both these implementations in parallel (which 
> would be kind of unfortunate)?
> And how does this affect xend? I see that in opposite to xm some 
> functionality of the xl tool works without having xend running (which I 
> find very handy, cause I spent countless hours during development to 
> just fix some weird xend issues just for calling xm info or xm vcpu-list).
> Was there a mail or a document I missed already explaining this?
> 

You didn't miss any email, we were planning on talking about this at
the next XenSummit.

Libxenlight is almost feature complete already: there are few things
missing, but not much.
Implementing the missing features and making the library rock solid are
our top priorities and we hope to get them done by the 4.1 release.
We also want to port xend and XCP to libxenlight to remove code
duplication and make it easier for xen and kernel developers to add new
features to the toolstacks.
The xl tool is going to be the main testing tool for libxenlight and is
going to provide a command line interface 99% compatible with xm; once
libxenlight is complete and robust we would like people that currently
use xend, especially developers, to try out xl.
Even though xend will be ported to libxenlight, xl is going to be
smaller and well tested, therefore we encourage people that don't need
advanced xend features, like managed domains or the XML RPC interface,
to use xl.

Re: future plans for libxl?

[Paolo Bonzini]

On 04/14/2010 05:48 PM, Stefano Stabellini wrote:
> Even though xend will be ported to libxenlight, xl is going to be
> smaller and well tested, therefore we encourage people that don't need
> advanced xend features, like managed domains or the XML RPC interface,
> to use xl.

Why not use libvirt for managed domains, and deprecate the XML RPC 
interface in favor of the libvirt RPC?

Paolo

Re: future plans for libxl?

[Stefano Stabellini]

On Wed, 14 Apr 2010, Paolo Bonzini wrote:
> On 04/14/2010 05:48 PM, Stefano Stabellini wrote:
> > Even though xend will be ported to libxenlight, xl is going to be
> > smaller and well tested, therefore we encourage people that don't need
> > advanced xend features, like managed domains or the XML RPC interface,
> > to use xl.
> 
> Why not use libvirt for managed domains, and deprecate the XML RPC 
> interface in favor of the libvirt RPC?
> 

Actually we thought about libvirt and we would really like to see a
libvirt port to libxenlight.
We would love to see some community contributions to make it happen.

Re: future plans for libxl?

[Andre Przywara]

Stefano Stabellini wrote:
> On Wed, 14 Apr 2010, Andre Przywara wrote:
>> Hi,
>>
>> what is the current master plan for libxl?
 >> ...
>> Was there a mail or a document I missed already explaining this?
>>
> 
> You didn't miss any email, we were planning on talking about this at
> the next XenSummit.
> 
> Libxenlight is almost feature complete already: there are few things
> missing, but not much.
I stumbled upon missing 'info' support, so I implemented a basic version 
of it. A few questions about it:
1.) Is there a fixed interface for libxenlight? I see libxc interfaces 
duplicated (like {xc,libxl_get}_physinfo), is that thought to provide a 
more stable interface than xc does (which changed quite a bit lastly). 
What about extending this interface? For complete xl info I need more 
field of the physinfo sysctl to be provided by libxl_get_physinfo, is it 
OK to extend the struct libxl_physinfo?
2.) I see a simple check of LIBXL_VERSION when doing libxl_ctx_init(). 
Is that meant to be that hard or is a compatibility scheme planned 
(like: support apps using on older interface and somehow emulate it?)

> Implementing the missing features and making the library rock solid are
> our top priorities and we hope to get them done by the 4.1 release.
> We also want to port xend and XCP to libxenlight to remove code
> duplication and make it easier for xen and kernel developers to add new
> features to the toolstacks.
That sounds great. What is the timeframe for this? Currently I do xend 
code in the first run and consider libxenlight only with lower priority. 
Shall I swap this?

> The xl tool is going to be the main testing tool for libxenlight and is
> going to provide a command line interface 99% compatible with xm; once
> libxenlight is complete and robust we would like people that currently
> use xend, especially developers, to try out xl.
I did, and I like it's speed (and relaxed dependency!). Although xm is 
not that slow, xl is noticeably faster:
brandon# time xm list
Name           ID   Mem VCPUs      State   Time(s)
Domain-0        0   512     1     r-----    194.5
     0.83s real     0.17s user     0.29s system
brandon# time xl list
Name           ID   Mem VCPUs      State   Time(s)
Domain-0        0   512     1        r--    194.6
     0.02s real     0.01s user     0.02s system
Not that speed actually matters with management tools, but it's very 
nice to have a quickly responding interface.

> Even though xend will be ported to libxenlight, xl is going to be
> smaller and well tested, therefore we encourage people that don't need
> advanced xend features, like managed domains or the XML RPC interface,
> to use xl.
That is good to know. We often have issue with xend not starting for 
this or that reason, hope that will be easier in the future.

Regards,
Andre.

P.S. Thanks for the great work, if you need some help in any area, tell 
the ML. Maybe a list of missing features or open issue on the Wiki is a 
good idea.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12

Re: future plans for libxl?

[David Markey]

[-- Attachment #1.1: Type: text/plain, Size: 3579 bytes --]

Are there any plans for python bindings for libxl?

I could probably do something up with ctypes, but I assume the ABI isnt at
all stable to do that yet.


On 15 April 2010 08:21, Andre Przywara <andre.przywara@amd.com> wrote:

> Stefano Stabellini wrote:
>
>> On Wed, 14 Apr 2010, Andre Przywara wrote:
>>
>>> Hi,
>>>
>>> what is the current master plan for libxl?
>>>
>> >> ...
>
>  Was there a mail or a document I missed already explaining this?
>>>
>>>
>> You didn't miss any email, we were planning on talking about this at
>> the next XenSummit.
>>
>> Libxenlight is almost feature complete already: there are few things
>> missing, but not much.
>>
> I stumbled upon missing 'info' support, so I implemented a basic version of
> it. A few questions about it:
> 1.) Is there a fixed interface for libxenlight? I see libxc interfaces
> duplicated (like {xc,libxl_get}_physinfo), is that thought to provide a more
> stable interface than xc does (which changed quite a bit lastly). What about
> extending this interface? For complete xl info I need more field of the
> physinfo sysctl to be provided by libxl_get_physinfo, is it OK to extend the
> struct libxl_physinfo?
> 2.) I see a simple check of LIBXL_VERSION when doing libxl_ctx_init(). Is
> that meant to be that hard or is a compatibility scheme planned (like:
> support apps using on older interface and somehow emulate it?)
>
>
>  Implementing the missing features and making the library rock solid are
>> our top priorities and we hope to get them done by the 4.1 release.
>> We also want to port xend and XCP to libxenlight to remove code
>> duplication and make it easier for xen and kernel developers to add new
>> features to the toolstacks.
>>
> That sounds great. What is the timeframe for this? Currently I do xend code
> in the first run and consider libxenlight only with lower priority. Shall I
> swap this?
>
>
>  The xl tool is going to be the main testing tool for libxenlight and is
>> going to provide a command line interface 99% compatible with xm; once
>> libxenlight is complete and robust we would like people that currently
>> use xend, especially developers, to try out xl.
>>
> I did, and I like it's speed (and relaxed dependency!). Although xm is not
> that slow, xl is noticeably faster:
> brandon# time xm list
> Name           ID   Mem VCPUs      State   Time(s)
> Domain-0        0   512     1     r-----    194.5
>    0.83s real     0.17s user     0.29s system
> brandon# time xl list
> Name           ID   Mem VCPUs      State   Time(s)
> Domain-0        0   512     1        r--    194.6
>    0.02s real     0.01s user     0.02s system
> Not that speed actually matters with management tools, but it's very nice
> to have a quickly responding interface.
>
>
>  Even though xend will be ported to libxenlight, xl is going to be
>> smaller and well tested, therefore we encourage people that don't need
>> advanced xend features, like managed domains or the XML RPC interface,
>> to use xl.
>>
> That is good to know. We often have issue with xend not starting for this
> or that reason, hope that will be easier in the future.
>
> Regards,
> Andre.
>
> P.S. Thanks for the great work, if you need some help in any area, tell the
> ML. Maybe a list of missing features or open issue on the Wiki is a good
> idea.
>
>
> --
> Andre Przywara
> AMD-Operating System Research Center (OSRC), Dresden, Germany
> Tel: +49 351 448-3567-12
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 5155 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: future plans for libxl?

[Vincent Hanquez]

On 15/04/10 08:21, Andre Przywara wrote:
> I stumbled upon missing 'info' support, so I implemented a basic version
> of it. A few questions about it:
> 1.) Is there a fixed interface for libxenlight? I see libxc interfaces
> duplicated (like {xc,libxl_get}_physinfo), is that thought to provide a
> more stable interface than xc does (which changed quite a bit lastly).
> What about extending this interface? For complete xl info I need more
> field of the physinfo sysctl to be provided by libxl_get_physinfo, is it
> OK to extend the struct libxl_physinfo?

yes, i've duplicated them for this exact purpose. it could work 
hand-in-hand with what i'm describing below.

for extending usually, you would just add a new field at the end of the
structure.

it's probably ok to extends the physinfo structure. however we tried
to separate some things that would be not very useful from a toolstack
point of view, compared to actually carrying all sorts of info of
questionable usefulness.

> 2.) I see a simple check of LIBXL_VERSION when doing libxl_ctx_init().
> Is that meant to be that hard or is a compatibility scheme planned
> (like: support apps using on older interface and somehow emulate it?)

it takes lots of resources to do a compat scheme. but eventually it 
could all be done with the LIBXL_VERSION check. if you upgrade
the library and something change, the previously compiled client
would still use a LIBXL_VERSION < compared to the current one in the 
library.

at this point, libxl could provide a mechanism to provide old -> new 
structure mechanism to provide automatic compatibilty with old 
userspace. note that it wouldn't cover function prototype change, but 
only structure change, and this is an extremly painful process
where you need to keep your old structure around, and have a 
(potentially) big fast switch case in function that need this compat layer.

it's much much simpler to just let client and library to be the exact 
same version, which is what the ctx_init function is doing at this point 
compared to the elaborate scheme of compat.

-- 
Vincent

Re: future plans for libxl?

[Vincent Hanquez]

On 15/04/10 08:26, David Markey wrote:
> Are there any plans for python bindings for libxl?

It's definitely something that would have to be done since there's a 
plan to port xend to libxl, but at the moment there's nothing available

there's an ocaml binding in the XCI-unstable tree, but it's probably not
what you're looking for :)

> I could probably do something up with ctypes, but I assume the ABI isnt
> at all stable to do that yet.

it should be fairly stable, and the only part left are new calls.
however there's still some area which are WIP, so i wouldn't expect
full ABI stability just yet.

-- 
Vincent

Re: future plans for libxl?

[Andre Przywara]

Vincent Hanquez wrote:
> On 15/04/10 08:21, Andre Przywara wrote:
>> I stumbled upon missing 'info' support, so I implemented a basic version
>> of it. A few questions about it:
>> 1.) Is there a fixed interface for libxenlight? I see libxc interfaces
>> duplicated (like {xc,libxl_get}_physinfo), is that thought to provide a
>> more stable interface than xc does (which changed quite a bit lastly).
>> What about extending this interface? For complete xl info I need more
>> field of the physinfo sysctl to be provided by libxl_get_physinfo, is it
>> OK to extend the struct libxl_physinfo?
> 
> yes, i've duplicated them for this exact purpose. it could work 
> hand-in-hand with what i'm describing below.
> 
> for extending usually, you would just add a new field at the end of the
> structure.
> 
> it's probably ok to extends the physinfo structure. however we tried
> to separate some things that would be not very useful from a toolstack
> point of view, compared to actually carrying all sorts of info of
> questionable usefulness.
OK, what is missing currently is nr_nodes, {hw,virt}_caps and the whole 
bunch of (currently in flux) NUMA information. I think the whole NUMA 
info should be moved into either a topology or a NUMA structure 
(together with libxl_get_... functions). But I'd like to see at least 
nr_nodes and the caps within the physinfo structure. One can debate 
about the nr_nodes fields, though.

What about xc_version(), by the way? This provides a lot of information 
currently shown in xm info, I didn't found any interface for that in 
libxenlight. Is it OK to implement it? Or shall I call xc_version() 
directly from xl.c?

>> 2.) I see a simple check of LIBXL_VERSION when doing libxl_ctx_init().
>> Is that meant to be that hard or is a compatibility scheme planned
>> (like: support apps using on older interface and somehow emulate it?)
> 
> it takes lots of resources to do a compat scheme. but eventually it 
> could all be done with the LIBXL_VERSION check. if you upgrade
> the library and something change, the previously compiled client
> would still use a LIBXL_VERSION < compared to the current one in the 
> library.
> 
> at this point, libxl could provide a mechanism to provide old -> new 
> structure mechanism to provide automatic compatibilty with old 
> userspace. note that it wouldn't cover function prototype change, but 
> only structure change, and this is an extremly painful process
> where you need to keep your old structure around, and have a 
> (potentially) big fast switch case in function that need this compat layer.
QEMU implements something in it's migration interface to support 
different version of the emulated devices. It's easier there though 
because they read each member explicitly from the stream and don't need 
to fiddle around with mapping structs.

> it's much much simpler to just let client and library to be the exact 
> same version, which is what the ctx_init function is doing at this point 
> compared to the elaborate scheme of compat.
I agree that the whole effort is probably not worth the gains. 
Especially since we have only one library one could update this together 
with the tools. If we came to some kind of stable interface, one could 
use the standard UNIX library versioning scheme.
The only question is if we can keep pace with the hypervisor 
development. If it introduces new features, hypercalls, extended 
structures do we really want to break compatibility or do we refrain 
from implementing new features?
I suppose that at least in the -unstable tree we don't care about 
compatibility and only keep a stable interface in the -testing trees, 
the libxl version could then be named after the stable hypervisor version.

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12

Re: future plans for libxl?

[Vincent Hanquez]

On 15/04/10 09:22, Andre Przywara wrote:
> OK, what is missing currently is nr_nodes, {hw,virt}_caps and the whole
> bunch of (currently in flux) NUMA information. I think the whole NUMA
> info should be moved into either a topology or a NUMA structure
> (together with libxl_get_... functions). But I'd like to see at least
> nr_nodes and the caps within the physinfo structure. One can debate
> about the nr_nodes fields, though.

Not sure about numa, it seems to be in flux in xen-unstable at the 
moment, so i'ld rather leave this interface alone, until it's sorted.

For the caps things, you might want to consider something a bit more 
high level than passing a bitfields through. For example you could 
actually transform the caps bitfields into an array of decoded values.
that's a bit more friendly to use from a user of libxl PoV.

> What about xc_version(), by the way? This provides a lot of information
> currently shown in xm info, I didn't found any interface for that in
> libxenlight. Is it OK to implement it? Or shall I call xc_version()
> directly from xl.c?

i think it would be nice to have a easy user interface that do a bunch
of xc_version calls and put them in a structure ready to be processed.

> I agree that the whole effort is probably not worth the gains.
> Especially since we have only one library one could update this together
> with the tools. If we came to some kind of stable interface, one could
> use the standard UNIX library versioning scheme.
> The only question is if we can keep pace with the hypervisor
> development. If it introduces new features, hypercalls, extended
> structures do we really want to break compatibility or do we refrain
> from implementing new features?

my take on it is, new features are more important than compat.
if it happens that we *have* to break an interface to implement a new 
feature, then it should be done; although probably trying to minimize 
the disruption is probably a good idea.

> I suppose that at least in the -unstable tree we don't care about
> compatibility and only keep a stable interface in the -testing trees,
> the libxl version could then be named after the stable hypervisor version.

hmm. I think even in unstable, we would try to keep compat as possible.
not sure what the policy with testing is going to be.

-- 
Vincent

Re: future plans for libxl?

[Stefano Stabellini]

On Thu, 15 Apr 2010, Andre Przywara wrote:
> Stefano Stabellini wrote:
> > On Wed, 14 Apr 2010, Andre Przywara wrote:
> >> Hi,
> >>
> >> what is the current master plan for libxl?
>  >> ...
> >> Was there a mail or a document I missed already explaining this?
> >>
> > 
> > You didn't miss any email, we were planning on talking about this at
> > the next XenSummit.
> > 
> > Libxenlight is almost feature complete already: there are few things
> > missing, but not much.
> I stumbled upon missing 'info' support, so I implemented a basic version 
> of it. A few questions about it:
> 1.) Is there a fixed interface for libxenlight? I see libxc interfaces 
> duplicated (like {xc,libxl_get}_physinfo), is that thought to provide a 
> more stable interface than xc does (which changed quite a bit lastly). 
> What about extending this interface? For complete xl info I need more 
> field of the physinfo sysctl to be provided by libxl_get_physinfo, is it 
> OK to extend the struct libxl_physinfo?

The idea is that a client of libxenlight does not need to use any
other library (libxc, libxenguest, xenstore) directly; libxenlight
should provide all the needed functionalities.
Of course libxenlight relies on libxc, libxenguest, xenstore, etc, to
implement them.


> > Implementing the missing features and making the library rock solid are
> > our top priorities and we hope to get them done by the 4.1 release.
> > We also want to port xend and XCP to libxenlight to remove code
> > duplication and make it easier for xen and kernel developers to add new
> > features to the toolstacks.
> That sounds great. What is the timeframe for this? Currently I do xend 
> code in the first run and consider libxenlight only with lower priority. 
> Shall I swap this?

We hope to get the xend port done by the end of this release cycle, but in
any case libxenlight should be stable at that time, so swapping sounds
like a good idea to me.

> 
> > The xl tool is going to be the main testing tool for libxenlight and is
> > going to provide a command line interface 99% compatible with xm; once
> > libxenlight is complete and robust we would like people that currently
> > use xend, especially developers, to try out xl.
> I did, and I like it's speed (and relaxed dependency!). Although xm is 
> not that slow, xl is noticeably faster:
> brandon# time xm list
> Name           ID   Mem VCPUs      State   Time(s)
> Domain-0        0   512     1     r-----    194.5
>      0.83s real     0.17s user     0.29s system
> brandon# time xl list
> Name           ID   Mem VCPUs      State   Time(s)
> Domain-0        0   512     1        r--    194.6
>      0.02s real     0.01s user     0.02s system
> Not that speed actually matters with management tools, but it's very 
> nice to have a quickly responding interface.
> 

I am glad to hear this. We didn't do any performance test yet, so this
comes as a very good news.

> P.S. Thanks for the great work, if you need some help in any area, tell 
> the ML. Maybe a list of missing features or open issue on the Wiki is a 
> good idea.
> 
 
This is great idea, maybe if we are still in time we could even create
an entry for GSoC.

Re: future plans for libxl?

[Ian Jackson]

Andre Przywara writes ("Re: [Xen-devel] future plans for libxl?"):
> 1.) Is there a fixed interface for libxenlight? I see libxc interfaces 
> duplicated (like {xc,libxl_get}_physinfo), is that thought to provide a 
> more stable interface than xc does (which changed quite a bit lastly). 

We intend libxl to have a reasonably stable API.  It won't have a
stable ABI because that's a lot of work.  Instead we'll just bump the
library soname each release just as we do for the underlying
libraries.

> What about extending this interface? For complete xl info I need more 
> field of the physinfo sysctl to be provided by libxl_get_physinfo, is it 
> OK to extend the struct libxl_physinfo?

Yes.

> 2.) I see a simple check of LIBXL_VERSION when doing libxl_ctx_init(). 
> Is that meant to be that hard or is a compatibility scheme planned 
> (like: support apps using on older interface and somehow emulate it?)

I don't think we have the effort to do a compatibility scheme.

Personally I think this check is not really useful.  The dynamic
linker will check our soname to avoid loading a libxl's from a
different major version of Xen.

If for some reason it is difficult to rebuild a libxl-using
application against a new libxl when a new version of Xen is released,
we will aim in general for it to be possible to continue to use the
application with the older version of libxl, although we may not
achieve this in every case.

> That sounds great. What is the timeframe for this? Currently I do xend 
> code in the first run and consider libxenlight only with lower priority. 
> Shall I swap this?

I would say yes.  libxl is already better than xend in some important
respects and we are working to improve its quality.

Thanks for your interest.

Ian.

Re: future plans for libxl?

[Ian Jackson]

David Markey writes ("Re: [Xen-devel] future plans for libxl?"):
> Are there any plans for python bindings for libxl?

We're planning to do some infrastructural work to make this a lot
easier.

> I could probably do something up with ctypes, but I assume the ABI isnt at
> all stable to do that yet.

The API is still undergoing some significant changes.  I would hold
off a few weeks if I were you.

But yes in principle we're keen to have language bindings including
for Python.

Ian.

Re: future plans for libxl?

[Ian Jackson]

Andre Przywara writes ("Re: [Xen-devel] future plans for libxl?"):
> OK, what is missing currently is nr_nodes, {hw,virt}_caps and the whole 
> bunch of (currently in flux) NUMA information. I think the whole NUMA 
> info should be moved into either a topology or a NUMA structure 
> (together with libxl_get_... functions). But I'd like to see at least 
> nr_nodes and the caps within the physinfo structure. One can debate 
> about the nr_nodes fields, though.

I would suggest that you should decide how you want to do it, but you
should feel free to submit patches against libxl to implement the
features you need - just as you would submit patches for the
hypervisor.

At some point soon we're going to be strongly encouraging people who
provide new features to do so via libxl (rather than, or in addition
to, xend).

> What about xc_version(), by the way? This provides a lot of information 
> currently shown in xm info, I didn't found any interface for that in 
> libxenlight. Is it OK to implement it? Or shall I call xc_version() 
> directly from xl.c?

In general, if there are interfaces missing then they should be added.
A user of libxl should not need to call libxc directly.  So yes, it
would be good to have a way to get the information provided by the
XENVER hypercall and xc_version.

Perhaps rather than expecting the libxl caller to include
xen/include/public/version.h, it would be better to have a single
libxc call that fills in a single structure by making all the relevant
calls and copying the data out.

Vincent, Stefano, what do you think ?

> [...]  If it introduces new features, hypercalls, extended 
> structures do we really want to break compatibility or do we refrain 
> >from implementing new features?

I think the plan is that we will break binary compatibility at Xen
releases.

> I suppose that at least in the -unstable tree we don't care about 
> compatibility and only keep a stable interface in the -testing trees, 
> the libxl version could then be named after the stable hypervisor version.

Exactly.

Ian.

Re: future plans for libxl?

[Ian Jackson]

Vincent Hanquez writes ("Re: [Xen-devel] future plans for libxl?"):
> hmm. I think even in unstable, we would try to keep compat as possible.

That's not going to be very possible.  I think we should rather prefer
to make a good interface than spend effort on compatibility shims or
make the interface less pleasant.

> not sure what the policy with testing is going to be.

If you mean "3.4-testing", "4.0-testing", I would say: there will be
complete ABI and API compatibility.

Ian.

Re: future plans for libxl?

[Vincent Hanquez]

On 15/04/10 14:53, Ian Jackson wrote:
> Perhaps rather than expecting the libxl caller to include
> xen/include/public/version.h, it would be better to have a single
> libxc call that fills in a single structure by making all the relevant
> calls and copying the data out.
>
> Vincent, Stefano, what do you think ?
>    
That's fine if it happens, but it's not like it's performance critical 
or will ever be.
not adding a new version hypercall and doing it in a series of 
hypercalls, means
that the code stays compatible with old hypervisor.

-- 
Vincent

Re: future plans for libxl?

[Ian Jackson]

Vincent Hanquez writes ("Re: [Xen-devel] future plans for libxl?"):
> On 15/04/10 14:53, Ian Jackson wrote:
> > Perhaps rather than expecting the libxl caller to include
> > xen/include/public/version.h, it would be better to have a single
> > libxc call that fills in a single structure by making all the relevant
> > calls and copying the data out.
...
> That's fine if it happens, but it's not like it's performance
> critical or will ever be.  not adding a new version hypercall and
> doing it in a series of hypercalls, means that the code stays
> compatible with old hypervisor.

Yes, that's what I was suggesting.  I don't think we need a new
hypercall.

Ian.

(resent with correct recipient list)

Re: future plans for libxl?

[Vincent Hanquez]

On 15/04/10 15:25, Ian Jackson wrote:
> Yes, that's what I was suggesting.  I don't think we need a new
> hypercall.
>    
ok; that would be perfectly fine then.

-- 
Vincent

RE: future plans for libxl?

[Xu, Jiajun]

Is there any example config file we can follow to create guest with 'xl'? If there is a reference doc or readme, it would be much convenient for user.
And seems following functions are not supported in 'xl' yet: HAP option, PCI-Passthrough-Strict-Check like ACS capability check, HVM S3 resume support by 'xm trigger' and function like 'xm info'.

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Stefano
> Stabellini
> Sent: Wednesday, April 14, 2010 11:49 PM
> To: xen-devel@lists.xensource.com
> Cc: Ian Jackson
> Subject: Re: [Xen-devel] future plans for libxl?
> 
> On Wed, 14 Apr 2010, Andre Przywara wrote:
> > Hi,
> >
> > what is the current master plan for libxl?
> > Currently I see that many features already implemented in Python are
> > again implemented in libxl (migration, CPU affinity).
> > Are the Python tools going to be replaced at some point in the future or
> > are they just reimplemented to be based upon libxl? For the NUMA guest
> > effort I would like to get some ideas on how to handle tool chain
> > implementation.
> > Or is it intended to have both these implementations in parallel (which
> > would be kind of unfortunate)?
> > And how does this affect xend? I see that in opposite to xm some
> > functionality of the xl tool works without having xend running (which I
> > find very handy, cause I spent countless hours during development to
> > just fix some weird xend issues just for calling xm info or xm vcpu-list).
> > Was there a mail or a document I missed already explaining this?
> >
> 
> You didn't miss any email, we were planning on talking about this at
> the next XenSummit.
> 
> Libxenlight is almost feature complete already: there are few things
> missing, but not much.
> Implementing the missing features and making the library rock solid are
> our top priorities and we hope to get them done by the 4.1 release.
> We also want to port xend and XCP to libxenlight to remove code
> duplication and make it easier for xen and kernel developers to add new
> features to the toolstacks.
> The xl tool is going to be the main testing tool for libxenlight and is
> going to provide a command line interface 99% compatible with xm; once
> libxenlight is complete and robust we would like people that currently
> use xend, especially developers, to try out xl.
> Even though xend will be ported to libxenlight, xl is going to be
> smaller and well tested, therefore we encourage people that don't need
> advanced xend features, like managed domains or the XML RPC interface,
> to use xl.

RE: future plans for libxl?

[Ian Jackson]

Xu, Jiajun writes ("RE: [Xen-devel] future plans for libxl?"):
> Is there any example config file we can follow to create guest with
> 'xl'?

You should be able to use example config files that work with "xm".

> If there is a reference doc or readme, it would be much
> convenient for user.

I agree, but we haven't written one yet.  We hope to add that during
the 4.1 release cycle.

>  And seems following functions are not
> supported in 'xl' yet: HAP option, PCI-Passthrough-Strict-Check like
> ACS capability check, HVM S3 resume support by 'xm trigger' and
> function like 'xm info'.

Thanks for that list.  But yes, we know there are some of the less
core features which haven't yet been implemented.  Contributions are
welcome!

Ian.

Re: future plans for libxl?

[Stefano Stabellini]

On Fri, 16 Apr 2010, Andre Przywara wrote:
> Ian Jackson wrote:
> > Xu, Jiajun writes ("RE: [Xen-devel] future plans for libxl?"):
> >>  And seems following functions are not
> >> supported in 'xl' yet: HAP option, PCI-Passthrough-Strict-Check like
> >> ACS capability check, HVM S3 resume support by 'xm trigger' and
> >> function like 'xm info'.
> > 
> > Thanks for that list.  But yes, we know there are some of the less
> > core features which haven't yet been implemented.  Contributions are
> > welcome!
> I have a working version of xl info ready.

great!

> I have still to think about the best approach for some fields to 
> propagate in libxl_get_version_info and libxl_get_physinfo (bitfields 
> vs. strings). I am not sure what the casual library user would like 
> more: Masking bits or strstr'ing for names? For reporting (as in xl 
> info) compiled strings are easier.
> Any suggestions? (I especially think about xen_caps, virt_caps and 
> xen_scheduler)
> 

feel free to submit your implementation; in general I think masking
bits make a better interface for a library.

Re: future plans for libxl?

[Ian Jackson]

Andre Przywara writes ("Re: [Xen-devel] future plans for libxl?"):
> I have a working version of xl info ready.

Great!

> I have still to think about the best approach for some fields to 
> propagate in libxl_get_version_info and libxl_get_physinfo (bitfields 
> vs. strings). I am not sure what the casual library user would like 
> more: Masking bits or strstr'ing for names? For reporting (as in xl 
> info) compiled strings are easier.
> Any suggestions? (I especially think about xen_caps, virt_caps and 
> xen_scheduler)

I think the C interface, that is, the interface to libxl, should be
in terms of bitfields.  xl should do conversion to strings.

Ian.

RE: future plans for libxl?

[Xu, Jiajun]

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Friday, April 16, 2010 6:47 PM
> To: Xu, Jiajun
> Cc: Stefano Stabellini; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] future plans for libxl?
> 
> Xu, Jiajun writes ("RE: [Xen-devel] future plans for libxl?"):
> > Is there any example config file we can follow to create guest with
> > 'xl'?
> 
> You should be able to use example config files that work with "xm".

Yes. I can create guest by 'xl' with example config file used by 'xm' after I provide the complete path for 'hvmloader' and 'qemu-dm'.

> > If there is a reference doc or readme, it would be much
> > convenient for user.
> 
> I agree, but we haven't written one yet.  We hope to add that during
> the 4.1 release cycle.

Thanks. It would be much better.

Best Regards,
Jiajun