Re: [Xen-devel] Xen 4.2 Release Plan / TODO

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-04-12 at 17:37 +0100, Dan Magenheimer wrote:
> > From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
> > 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.

OK, this sounds good, thanks.

> 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.

Should libxl_tmem_destroy be a public function or should it solely be
called from libxl_domain_destroy? I notice that there is an xl
tmem-destroy so I presume the former?

We might consider adding a dummy ao_how to this one I suppose.

> 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.

It all sounds fine, I more curious about tmem_destroy than worried.

Ian.

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



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