This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] LTTng-Xen Buffer shared between the hypervisor and a dom

To: Mathieu Desnoyers <compudj@xxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] LTTng-Xen Buffer shared between the hypervisor and a dom0 process
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Thu, 08 Mar 2007 10:02:44 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 08 Mar 2007 02:01:59 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070308092627.GB30932@Krystal>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdhaOpfKPhSFM1cEduQtwAX8io7RQ==
Thread-topic: [Xen-devel] LTTng-Xen Buffer shared between the hypervisor and a dom0 process
User-agent: Microsoft-Entourage/
On 8/3/07 09:26, "Mathieu Desnoyers" <compudj@xxxxxxxxxxxxxxxxxx> 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

Xen-devel mailing list