From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [patch 1/4] KVM: MMU audit: update count_writable_mappings / count_rmaps Date: Tue, 09 Jun 2009 15:40:56 +0300 Message-ID: <4A2E5858.6010802@redhat.com> References: <20090602213655.640083007@localhost.localdomain> <20090602214226.820226306@localhost.localdomain> <4A2CD8B8.2050308@redhat.com> <20090609123341.GA6453@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sheng@linux.intel.com, kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from mx2.redhat.com ([66.187.237.31]:54975 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752011AbZFIMk7 (ORCPT ); Tue, 9 Jun 2009 08:40:59 -0400 In-Reply-To: <20090609123341.GA6453@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: Marcelo Tosatti wrote: >> Semi-related: we should set up a new exit code to halt the VM so it can >> be inspected, otherwise all those printks and dump_stack()s will quickly >> overwhelm the logging facilities. >> > > Can you clarify on the halt exit code? > set a bit that tells KVM_RUN to quit (like KVM_EXIT_UNKNOWN), when userspace sees it it vm_stop()s, waiting for someone to dig in. Clean logs, clean state. > Because for other exit codes which similar behaviour is wanted, say, > unhandled vm exit, the policy can be handled in userspace (and the > decision to halt or not seems better suited to happen there). So perhaps > KVM_EXIT_MMU_AUDIT_FAILED? > Yes, the name was bad. We can do KVM_EXIT_INTERNAL_ERROR and have a maintainer_name field in the union to choose who will handle it. > I wondered before whether it would be good to stop auditing on the first > error, but gave up on the idea. > It's harder without exceptions. -- error compiling committee.c: too many arguments to function