From mboxrd@z Thu Jan  1 00:00:00 1970
From: Pekka Enberg <penberg@kernel.org>
Subject: Re: [PATCH 5/5] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_SOCKET
Date: Thu, 14 Jul 2011 16:17:11 +0300
Message-ID: <1310649431.9498.28.camel@jaguar>
References: <1309927078-5983-1-git-send-email-levinsasha928@gmail.com>
	 <1310469824.2393.22.camel@sasha>	 <4E1C2F59.90600@redhat.com>
	 <CAOJsxLHAo0hNcRRSdN2sZiDZc0+SLVui9VW6VCYukx7kEWKXaQ@mail.gmail.com>
	 <CAOJsxLEfZcXaeNPMh=k8y9WqcH=qL-aGB1vJBb=xc_bis7Lcdw@mail.gmail.com>
	 <4E1D442E.6090308@redhat.com>
	 <CAOJsxLGWjd18MiU7j+RbiUFWXbeKF4-5aahQL5kXagNszrA=QQ@mail.gmail.com>
	 <4E1D9623.70801@redhat.com>
	 <CAOJsxLH3Qton9VfFMOdJgCdCMNDzzQf+x8aGwuDDnfeigTEF=Q@mail.gmail.com>
	 <4E1D9E75.1070901@redhat.com>	<4E1E9A3B.7090200@kernel.org>
	 <4E1EA455.4010608@redhat.com>
	 <CAOJsxLG8UnE2SAKB1rdNYMM78DXFK9p+tem8Nc4jSpgMJcK31g@mail.gmail.com>
	 <4E1EA8A2.9020304@redhat.com>
	 <CAOJsxLE-fbyiEtGxC8rA=X3NqM6+116YENugm1Y511Ko+H7eCg@mail.gmail.com>
	 <4E1EBB7A.3030809@redhat.com>
	 <CAOJsxLHSeRuTOoiJssyrELRx-eXok3WinLr_+_G4dB+yHNBKdg@mail.gmai! l.com>
	 <4E1ED913.6070003@redhat.com> <1310646737.21171.23.camel@lappy>
	 <4E1EE519.1020608@redhat.com> <1310648409.21171.34.camel@lappy>
	 <4E1EE9A5.8040306@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Sasha Levin <levinsasha928@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, kvm@vger.kernel.org,
	Ingo Molnar <mingo@elte.hu>,
	Marcelo Tosatti <mtosatti@redhat.com>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from filtteri6.pp.htv.fi ([213.243.153.189]:55430 "EHLO
	filtteri6.pp.htv.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754585Ab1GNNRO (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 14 Jul 2011 09:17:14 -0400
In-Reply-To: <4E1EE9A5.8040306@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Thu, 2011-07-14 at 16:05 +0300, Avi Kivity wrote:
> On 07/14/2011 04:00 PM, Sasha Levin wrote:
> > >
> > >  Why?  virtio is mature.  It's not some early boot thing which fails and
> > >  kills the guest.  Even if you get an oops, usually the guest is still alive.
> >
> > virtio is mature, /tools/kvm isn't :)
> > >
> > >  >  It's not just virtio which can fail running on virtio-console, it's also
> > >  >  the threadpool, the eventfd mechanism and even the PCI management
> > >  >  module. You can't really debug it if you can't depend on your debugging
> > >  >  mechanism to properly work.
> > >
> > >  Wait, those are guest things, not host things.
> >
> > Yes, as you said in the previous mail, both KVM and virtio are very
> > stable. /tools/kvm was the one who was being debugged most of the time.
> 
> I still don't follow.  The guest oopses? dmesg | less.  An issue with 
> tools/kvm? gdb -p `pgrep kvm`.

When I was debugging tools/kvm virtio code, I used to 'instrument' the
guest kernel with printk() calls which helped a lot.

Also, a bug in tools/kvm can manifest in many interesting ways in the
guest kernel during boot, for example. You can't do dmesg then and gdb
won't save you. I think you've lived too long in the table KVM and Qemu
land to remember how important reliable printk() is for development.

			Pekka