From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030800Ab2CNNIJ (ORCPT ); Wed, 14 Mar 2012 09:08:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51921 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965023Ab2CNNIG (ORCPT ); Wed, 14 Mar 2012 09:08:06 -0400 Message-ID: <4F609822.7050502@redhat.com> Date: Wed, 14 Mar 2012 15:07:46 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Wen Congyang CC: Gleb Natapov , "Daniel P. Berrange" , kvm list , qemu-devel , "linux-kernel@vger.kernel.org" , KAMEZAWA Hiroyuki , Jan Kiszka , Amit Shah Subject: Re: [PATCH 0/2 v3] kvm: notify host when guest panicked References: <4F5DBC26.7060204@cn.fujitsu.com> <4F5DD0FD.9070904@redhat.com> <20120313091843.GB3800@redhat.com> <4F5F25BF.7060100@redhat.com> <4F6056FE.3020202@cn.fujitsu.com> <4F6063C8.8010005@redhat.com> <4F606A7C.9090900@cn.fujitsu.com> <4F606DCC.3020908@redhat.com> <4F60726E.3090807@cn.fujitsu.com> <4F607325.6050607@redhat.com> <20120314104608.GU2304@redhat.com> <4F607789.4010109@redhat.com> <4F607CE4.2060809@cn.fujitsu.com> In-Reply-To: <4F607CE4.2060809@cn.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/14/2012 01:11 PM, Wen Congyang wrote: > > > > I don't think we want to use the driver. Instead, have a small piece of > > code that resets the device and pushes out a string (the panic message?) > > without any interrupts etc. > > > > It's still going to be less reliable than a hypercall, I agree. > > Do you still want to use complicated and less reliable way? Are you willing to try it out and see how complicated it really is? While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses. > I think the other ones prefer to touch the hypervisor. I understand the sentiment. Your patches are simple and easy. But my feeling is that the kernel has become too complicated already and I'm looking for ways to limit changes. -- error compiling committee.c: too many arguments to function