From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030754Ab2CNKF5 (ORCPT ); Wed, 14 Mar 2012 06:05:57 -0400 Received: from cn.fujitsu.com ([222.73.24.84]:14938 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1030712Ab2CNKFz (ORCPT ); Wed, 14 Mar 2012 06:05:55 -0400 X-IronPort-AV: E=Sophos;i="4.73,583,1325433600"; d="scan'208";a="4533497" Message-ID: <4F606A7C.9090900@cn.fujitsu.com> Date: Wed, 14 Mar 2012 17:53:00 +0800 From: Wen Congyang User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100413 Fedora/3.0.4-2.fc13 Thunderbird/3.0.4 MIME-Version: 1.0 To: Avi Kivity CC: "Daniel P. Berrange" , kvm list , qemu-devel , "linux-kernel@vger.kernel.org" , KAMEZAWA Hiroyuki , Jan Kiszka , Gleb Natapov , Amit Shah Subject: Re: [PATCH 0/2 v3] kvm: notify host when guest panicked References: <4F58664D.1070800@cn.fujitsu.com> <4F58943E.1050402@redhat.com> <4F595B31.9090301@cn.fujitsu.com> <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> In-Reply-To: <4F6063C8.8010005@redhat.com> X-MIMETrack: Itemize by SMTP Server on mailserver/fnst(Release 8.5.1FP4|July 25, 2010) at 2012-03-14 17:49:04, Serialize by Router on mailserver/fnst(Release 8.5.1FP4|July 25, 2010) at 2012-03-14 18:03:51, Serialize complete at 2012-03-14 18:03:51 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At 03/14/2012 05:24 PM, Avi Kivity Wrote: > On 03/14/2012 10:29 AM, Wen Congyang wrote: >> At 03/13/2012 06:47 PM, Avi Kivity Wrote: >>> On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: >>>> On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: >>>>> On 03/12/2012 11:04 AM, Wen Congyang wrote: >>>>>> Do you have any other comments about this patch? >>>>>> >>>>> >>>>> Not really, but I'm not 100% convinced the patch is worthwhile. It's >>>>> likely to only be used by Linux, which has kexec facilities, and you can >>>>> put talk to management via virtio-serial and describe the crash in more >>>>> details than a simple hypercall. >>>> >>>> As mentioned before, I don't think virtio-serial is a good fit for this. >>>> We want something that is simple & guaranteed always available. Using >>>> virtio-serial requires significant setup work on both the host and guest. >>> >>> So what? It needs to be done anyway for the guest agent. >>> >>>> Many management application won't know to make a vioserial device available >>>> to all guests they create. >>> >>> Then they won't know to deal with the panic event either. >>> >>>> Most administrators won't even configure kexec, >>>> let alone virtio serial on top of it. >>> >>> It should be done by the OS vendor, not the individual admin. >>> >>>> The hypercall requires zero host >>>> side config, and zero guest side config, which IMHO is what we need for >>>> this feature. >>> >>> If it was this one feature, yes. But we keep getting more and more >>> features like that and we bloat the hypervisor. There's a reason we >>> have a host-to-guest channel, we should use it. >>> >> >> I donot know how to use virtio-serial. > > I don't either, copying Amit. > >> I start vm like this: >> qemu ...\ >> -device virtio-serial \ >> -chardev socket,path=/tmp/foo,server,nowait,id=foo \ >> -device virtserialport,chardev=foo,name=port1 ... >> >> You said that there are too many channels. Does it mean /tmp/foo is a channel? > > Probably. Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right? If so, is this channel visible to guest userspace? If the channle is visible to guest userspace, the program running in userspace may write the same message to the channel. Thanks Wen Congyang >