Re: Xen 4.2 Release Plan / TODO

[Dan Magenheimer <dan.magenheimer@oracle.com>]

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Thursday, April 12, 2012 1:59 AM
> To: Ian Jackson; Dan Magenheimer
> Cc: xen-devel
> Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO
> 
> On Thu, 2012-04-12 at 08:35 +0100, Ian Campbell wrote:
> >
> > > ]   char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int
> > use_long);
> > > ]   int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
> > > ]   int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
> > > ]   int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
> > > ]   int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
> > > ]                      uint32_t set);
> > > ]   int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid, char*
> > uuid,
> > > ]                              int auth);
> > > ]   int libxl_tmem_freeable(libxl_ctx *ctx);
> > >
> > > Not sure about the tmem calls.
> >
> > Me neither.
> 
> Dan,
> 
> We want to declare the libxl 4.2 API as "stable" so we are trying to
> determine whether any of these functions need to be made potentially
> asynchronous or not, i.e. if they may be "slow" per the definition under
> the comment "Machinery for asynchronous operations ("ao")" in
> tools/libxl/libxl_internal.h, effectively if they may block for extended
> periods.
> 
> If they were then we would possibly want to change the API to take an
> "ao_how" as described under "Some libxl operations can take a long time"
> in tools/libxl/libxl.h
> 
> If they are "fast" today but could potentially be slow in the future
> then we may be able to make the trivial API change but keep the
> synchronous implementation (depending on the specifics). It's quite late
> in the day so if the functions are "slow" then this would be the
> preferred option at this stage.
> 
> Otherwise the alternative is that we have to maintain these interfaces
> going forward (for compat) and perhaps be forced introduce a new
> parallel async interface in the future. Annoying but not the end of the
> world.

Hi Ian(s) --

After reading libxl.h, I'm not absolutely positive I understand
all the conditions that would cause you to label a function as
"slow" but I believe all the libxl_tmem_* functions are "fast".
All of them are strictly "call the hypervisor, wait for it to
return" and none of the hypercalls (actually which are variations of
the one tmem hypercall) require a callback to dom0 or to the
calling guest... they all complete entirely inside the hypervisor.

Libxl_tmem_destroy may take a long time as it has to walk
through and free some potentially very large data structures,
but it is only used at domain destruction.

Libxl_tmem_list does allocate some memory in userland that the
hypercall fills synchronously (with ascii-formatted statistics/counters
maintained entirely by the tmem code in the hypervisor).

If any of the above raises any alarms/concerns, let me know,
else no need to asynchronizify any of the tmem functions in libxl.

(Zhigang cc'ed since he's more familiar with the libxl layer than I.)

Dan