From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eduardo Habkost Subject: Re: [PATCH 0/2] kvmtrace: Allow user to clean up stale trace setup Date: Wed, 22 Oct 2008 16:24:50 -0200 Message-ID: <20081022182450.GP27959@blackpad> References: <1224696928-22187-1-git-send-email-ehabkost@redhat.com> <5d6222a80810221042n44684c1fpdd5ea3f8cadb88db@mail.gmail.com> <20081022175454.GM27959@blackpad> <5d6222a80810221105x4446583w3e7f09b8a4957015@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , kvm@vger.kernel.org To: Glauber Costa Return-path: Received: from mx2.redhat.com ([66.187.237.31]:57186 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752630AbYJVSZL (ORCPT ); Wed, 22 Oct 2008 14:25:11 -0400 Content-Disposition: inline In-Reply-To: <5d6222a80810221105x4446583w3e7f09b8a4957015@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Oct 22, 2008 at 04:05:01PM -0200, Glauber Costa wrote: > On Wed, Oct 22, 2008 at 3:54 PM, Eduardo Habkost wrote: > > On Wed, Oct 22, 2008 at 03:42:27PM -0200, Glauber Costa wrote: > >> On Wed, Oct 22, 2008 at 3:35 PM, Eduardo Habkost wrote: > >> > If kvmtrace crashes or gets killed while collecting trace data, stale > >> > trace setup information may be enabled on the kernel, and currently > >> > there is no way to force the previous trace setup to be overwritten > >> > or disabled. > >> > > >> > The following two patches against kvm-userspace will add a new > >> > command-line option to kvmtrace (-f), that will allow the user to forcibly > >> > clean up an existing trace setup before enabling trace. > >> > >> Why can't we simply disable potential stale setups everytime, before we start? > >> The option would then not be needed > > > > Another kvmtrace instance may be already running. Do we want to kill > > its tracing setup without asking, by default? > do we allow more than one instance? No. That's why the current behaviour is to fail when there is another instance running. > > Note that if the answer is "yes", we also have the problem in which we > have two or three instances in flight. > Which one of them does the command kill ? Currently, the behaviour of ioctl(KVM_TRACE_DISABLE) when another kvmtrace instance is still running will be: - the previous instance will be still running, but getting no data - the new instance will fail when trying to enable tracing (because the old instance is keeping the old debugfs files open) IMO, aborting by default (and making the user aware that something is wrong if he needs to use -f) looks better than breaking both instances. -- Eduardo