From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Xen 4.2 Release Plan / TODO Date: Thu, 12 Apr 2012 17:45:32 +0100 Message-ID: <1334249132.16387.147.camel@zakaz.uk.xensource.com> References: <1333362402.25602.36.camel@zakaz.uk.xensource.com> <20357.44324.27939.514126@mariner.uk.xensource.com> <1334216141.12209.236.camel@dagon.hellion.org.uk> <1334217564.12209.250.camel@dagon.hellion.org.uk> <2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <2973456e-3cb6-4ade-97d6-ed2e816c8e1d@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dan Magenheimer Cc: Zhigang Wang , Ian Jackson , xen-devel List-Id: xen-devel@lists.xenproject.org On Thu, 2012-04-12 at 17:37 +0100, Dan Magenheimer wrote: > > 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. 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