Re: LTTng-Xen Buffer shared between the hypervisor and a dom0 process

[Keir Fraser <keir@xensource.com>]

On 8/3/07 09:26, "Mathieu Desnoyers" <compudj@krystal.dyndns.org> 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