From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] kvm: notify host when guest paniced Date: Wed, 29 Feb 2012 12:48:57 +0200 Message-ID: <4F4E0299.9080800@redhat.com> References: <4F4AF1FB.6000903@cn.fujitsu.com> <4F4CB926.6050600@redhat.com> <4F4D7F5E.5040202@cn.fujitsu.com> <4F4DF4C6.90609@redhat.com> <20120229095557.GE24600@redhat.com> <4F4DF749.7060507@redhat.com> <20120229100550.GF24600@redhat.com> <4F4DF913.5030809@redhat.com> <20120229104449.GG24600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Wen Congyang , kvm list , KAMEZAWA Hiroyuki , "Daniel P. Berrange" , linux-kernel@vger.kernel.org, qemu-devel To: Gleb Natapov Return-path: In-Reply-To: <20120229104449.GG24600@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 02/29/2012 12:44 PM, Gleb Natapov wrote: > > > > > > > Yes, crash can be so severe that it is not even detected by a kernel > > > itself, so not OOPS message even printed. But in most cases if kernel is > > > functional enough to print OOPS it is functional enough to call single > > > hypercall instruction. > > > > Why not print the oops to virtio-serial? Or even just a regular serial > > port? That's what bare metal does. > > > The more interface is complex the more chances it will fail during > panic. Regular serial is likely more reliable than virtio-serial. > Hypercall is likely more reliable than uart. On serial user can > fake panic notification. The serial device is under control of the kernel, so the user can only access it if the kernel so allows. > Can this be problematic? >>From the point of view of the guest, yes, it can generate support calls in fill up the admin's dump quota. From the point of view of the host, there's no difference between the guest's admin and a random user. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39899) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2h6D-0004kL-H7 for qemu-devel@nongnu.org; Wed, 29 Feb 2012 05:49:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S2h5n-0007xv-9Y for qemu-devel@nongnu.org; Wed, 29 Feb 2012 05:49:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:16560) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2h5n-0007xM-1N for qemu-devel@nongnu.org; Wed, 29 Feb 2012 05:49:07 -0500 Message-ID: <4F4E0299.9080800@redhat.com> Date: Wed, 29 Feb 2012 12:48:57 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4F4AF1FB.6000903@cn.fujitsu.com> <4F4CB926.6050600@redhat.com> <4F4D7F5E.5040202@cn.fujitsu.com> <4F4DF4C6.90609@redhat.com> <20120229095557.GE24600@redhat.com> <4F4DF749.7060507@redhat.com> <20120229100550.GF24600@redhat.com> <4F4DF913.5030809@redhat.com> <20120229104449.GG24600@redhat.com> In-Reply-To: <20120229104449.GG24600@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] kvm: notify host when guest paniced List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: kvm list , qemu-devel , linux-kernel@vger.kernel.org, KAMEZAWA Hiroyuki On 02/29/2012 12:44 PM, Gleb Natapov wrote: > > > > > > > Yes, crash can be so severe that it is not even detected by a kernel > > > itself, so not OOPS message even printed. But in most cases if kernel is > > > functional enough to print OOPS it is functional enough to call single > > > hypercall instruction. > > > > Why not print the oops to virtio-serial? Or even just a regular serial > > port? That's what bare metal does. > > > The more interface is complex the more chances it will fail during > panic. Regular serial is likely more reliable than virtio-serial. > Hypercall is likely more reliable than uart. On serial user can > fake panic notification. The serial device is under control of the kernel, so the user can only access it if the kernel so allows. > Can this be problematic? >>From the point of view of the guest, yes, it can generate support calls in fill up the admin's dump quota. From the point of view of the host, there's no difference between the guest's admin and a random user. -- error compiling committee.c: too many arguments to function