From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: LTTng-Xen Buffer shared between the hypervisor and a dom0 process Date: Thu, 08 Mar 2007 10:02:44 +0000 Message-ID: References: <20070308092627.GB30932@Krystal> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070308092627.GB30932@Krystal> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mathieu Desnoyers Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 8/3/07 09:26, "Mathieu Desnoyers" wrote: > Not exactly : when xen wants to end writing to its buffers, it disables > writing, does a subbuffer switch and sets the buffer "finalize" flag to > 1. It then sends a VIRQ to lttd-xen. lttd-xen reads the last subbuffers > (using a get_cpu/put_cpu and get_facilities/put_facilities cmd of the > ltt hypercall to select the offset to read and then reads the buffers) > and is then ready to release the buffers. At that specific point, I > would like all the trace information (xmalloc'd and xenheap shared) to > be freed. But I would also like it to be freed if lttd is killed (so > when file descriptors and memory maps are freed). This latter part sounds kind of tricky to do cleanly. How do we distinguish between refcount being zero because lttd-xen has died, versus refcount being zero because lttd-xen hasn't yet mapped the buffers? I think it's hard to reliably provide process scope for physical resources without assistance from the guest kernel (but I'll be happy to be proven wrong!). In xentrace (which incidentally is this intended to replace? Or complement?) the buffer lifetime is quite separate from the lifetime of xentrace daemon invocations. That's just what turned out to be easiest to implement with no guest kernel modifications. However if that's not a good model for LTTng then we can certainly consider if extra support, in guest kernel or in hypervisor, is warranted. -- Keir