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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> -----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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel