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: Sat, 10 Mar 2007 17:18:25 +0000 Message-ID: References: <20070310030230.GC9323@Krystal> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070310030230.GC9323@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 10/3/07 03:02, "Mathieu Desnoyers" wrote: > I see your idea : the other way around would be to have lttctl-xen > return an error if the buffers are actually mapped. It would however > require some changes to the buffer scheme, as I support multiple > start/stop tracing while keeping the same buffers and the same lttd-xen > daemon. I would have to create a new ltt sub-hypercall to finalize the > buffers, which would make lttd-xen write them to disk and exit. > > Controlling tracing from within a guest kernel or within the hypervisor > would start to be a tricky business, as you would have to explicitely > keep track of lttd-xen presence before freeing the buffers. Are the buffer pages only ever shared with domain0? In that case we don't need to worry about Xen holding a reference on the pages that would stop the domain from ever being destroyed (since dom0 is never destroyed). In which case I think you can just take an extra count_info reference in Xen, which you drop on 'lttctl-xen -r'. You'll need an extra page flag so that the IS_XEN_HEAP_FRAME case in free_domheap_pages() actually frees the page rather than leaving that job for later. -- Keir