Re: [Xen-devel] Volunteers required for 4.2 TODO items (Re: 4.2 TODO update)

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2012-03-12 at 16:59 +0000, Lin Ming wrote:
> On Tue, Mar 13, 2012 at 12:40 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> wrote:
> > On Mon, 2012-03-12 at 16:00 +0000, Lin Ming wrote:
> >> On Mon, Mar 12, 2012 at 8:22 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> >> wrote:
> >> > On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> >> >> There are several things below which are in need of a volunteer to take 
> >> >> care of them...
> >>
> >> Hi,
> >>
> >> I'm a newcomer.
> >> Could you share more details about the requirements?
> >>
> >> >
> >> > Specifically:
> >> >
> >> >> tools, blockers:
> >> >> [...]
> >> >>       * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)
> >>
> >> Are these parameters to be added for some xl subcommand?
> >> What are they used for?
> >
> > These should be options which can be specified in the domain
> > configuration file for HVM guests. They control the offset of the
> > guest-visible emulated RTC from the host time -- IOW they control the
> > time which the guest sees.
> >
> > These options are supported by xm/xend and need to be implemented for xl
> > in a compatible way. This means exposing suitable fields in the libxl
> > API (probably as fields in libxl_domain_build_info) and arranging for xl
> > to parse the configuration file options.
> >
> > Some amount of reverse engineering of xend will be required to figure
> > out what the actual meaning of those options in order to implement in a
> > compatible way but AFAIK rtc_timeoffset is the offset between host time
> > and guest time. localtime I think means to specify whether the emulted
> > RTC appears as UTC or is offset by the host.
> >
> > Having figured out the meaning libxl needs to arrange to call
> > xc_domain_set_time_offset with the right values.
> >
> > I think much of the related xend code is in
> > tools/python/xen/xend/image.py but you might need to grep about a bit.
> >
> >> >>       * Domain 0 block attach & general hotplug when using qdisk backend
> >> >>         (need to start qemu as necessary etc)
> >> >> tools, nice to have:
> >> >> [...]
> >> >>       * xl support for autospawning vncviewer (vncviewer=1 or otherwise)
> >>
> >> Could you tell more detail?
> >
> > xm/xend supports a configuration file option "vncviewer=1" which causes
> > xend to automatically spawn vncviewer with the correct options (e.g.
> > port number) when doing "xm create". We would like the same for "xl
> > create".
> >
> > As well as a config file option I think a command line option to "xl
> > create" would also be useful, similar to '-c' which automatically
> > connects to the virtual serial console. e.g '-V' perhaps.
> >
> > I guess we would want a libxl interface similar to
> > libxl_primary_console_exec and xl support to call it when appropriate.
> > overall it should look a lot like the console spawning stuff.
> >
> >> >>         (Nobody AFAICT)
> >> >>       * support for vif "rate" parameter (No one, AFAICT)
> >>
> >> It's a kernel module parameter(xen-4.1.2/tools/vnet/vnet-module), right?
> >
> > I don't think so, this is network rate limiting as implemented by
> > netback. Mathieu Gagnà is already taking care of this so I won't go into
> > any further detail (which is lucky, because I'm fuzzy about the details
> > myself).
> >
> >>
> >> >
> >> > #1,#3 & #4 are reasonably simple libxl/xl features possibly suitable for
> >> > a newcomer who is interested in getting started with toolstack level
> >> > stuff.
> >> >
> >> > #2 is a bit more involved.
> >> >
> >> > Any takers?
> >>
> >> I'm a new comer and I'd like to get start from here.
> >
> > Please do let us know if you decide to take on one of the tasks.
> 
> Thanks for the detail explanation.
> I take #1.

Great!

> Do we have a deadline for the patch?

See the "Xen 4.2 release plan" email which I sent to the list this
morning for a broad outline

Since these are in the "nice to have" category and are pretty small and
self contained I think that even if they miss 4.2.0 they can go in to
unstable in the 4.3 dev cycle and be obvious candidates for backporting
to 4.2.1.

Ian.

> I'll need time to ramp up the code.
> 
> Thanks,
> Lin Ming
> 
> >
> > Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel