From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: KVM git hangs with if=virtio (works under kvm 0.12.3) Date: Wed, 7 Jul 2010 12:38:11 +0300 Message-ID: <20100707093811.GZ4689@redhat.com> References: <1278041518.10459.48.camel@geektop> <20100705121759.GP4689@redhat.com> <20100705124112.GR4689@redhat.com> <20100707091358.GY4689@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: ewheeler , kvm@vger.kernel.org, Anthony Liguori , Avi Kivity To: Stefan Hajnoczi Return-path: Received: from mx1.redhat.com ([209.132.183.28]:44657 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751702Ab0GGJiP convert rfc822-to-8bit (ORCPT ); Wed, 7 Jul 2010 05:38:15 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jul 07, 2010 at 10:36:17AM +0100, Stefan Hajnoczi wrote: > 2010/7/7 Gleb Natapov : > > On Wed, Jul 07, 2010 at 10:03:31AM +0100, Stefan Hajnoczi wrote: > >> 2010/7/5 Gleb Natapov : > >> > On Mon, Jul 05, 2010 at 01:36:08PM +0100, Stefan Hajnoczi wrote: > >> >> 2010/7/5 Gleb Natapov : > >> >> > On Mon, Jul 05, 2010 at 01:11:25PM +0100, Stefan Hajnoczi wro= te: > >> >> >> On Fri, Jul 2, 2010 at 9:07 AM, Stefan Hajnoczi wrote: > >> >> >> > On Fri, Jul 2, 2010 at 4:31 AM, ewheeler wrote: > >> >> >> >> Hello all, > >> >> >> >> > >> >> >> >> I'm booting a CentOS kernel under today's KVM git and it = hangs after > >> >> >> >> initializing the serial port when the drive if=3Dvirtio, = but not when > >> >> >> >> drive if=3Dide. =9ALook close---this is not a "forgot to = add virtio_blk" > >> >> >> >> problem. =9AIf I use 0.12.3 from Ubuntu 10.04 it works pr= operly. > >> >> >> >> > >> >> >> >> Reproduction: > >> >> >> >> > >> >> >> >> Using kvm 0.12.3 on ubuntu 10.04 (1:84+dfsg-0ubuntu16+0.1= 2.3+noroms > >> >> >> >> +0ubuntu9) it will work properly: > >> >> >> >> > >> >> >> >> =9Aqemu-system-x86_64 -drive file=3Ddummy-disk-image,if=3D= virtio \ > >> >> >> >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A-kernel vm= linuz-2.6.18-194.3.1.el5.centos.plus > >> >> >> >> > >> >> >> >> As expected, the kernel panics unable to mount root (good= -boot.png). > >> >> >> >> This makes sense, as "dummy-disk-image" is 1MB of 0x00 by= tes. > >> >> >> >> > >> >> >> >> ---However---if I use today's git (2010-07-01) of kvm: > >> >> >> >> > >> >> >> >> =9A /usr/local/kvm-git/bin/qemu-system-x86_64 -drive file= =3Ddummy-disk-image,if=3Dvirtio \ > >> >> >> >> =9A =9A =9A =9A-kernel vmlinuz-2.6.18-194.3.1.el5.centos.= plus > >> >> >> >> > >> >> >> >> This hangs just after initializing the Serial device (obt= ained by adding > >> >> >> >> -serial stdio -append console=3DttyS0): > >> >> >> >> > >> >> >> >> Note that this only happens with the disk interface set t= o virtio > >> >> >> >> (if=3Dvirtio). =9AIt works fine for ide (if=3Dide). > >> >> >> >> > >> >> >> >> > >> >> >> >> Am I doing something wrong here? > >> >> >> >> Is anyone else having this problem? > >> >> >> > > >> >> >> > I have seen this issue with a RHEL 5.5 guest running under > >> >> >> > qemu-kvm.git. =9AIt boots a new guest fine but hangs as yo= u described > >> >> >> > with the RHEL 5.5 kernel. =9AI have not investigated. > >> >> >> > >> >> >> This issue is affected by extboot, a feature that enables bo= oting from > >> >> >> virtio-blk devices. =9AI have just sent a patch to the KVM m= ailing list > >> >> >> to restore extboot functionality which has been broken in > >> >> >> qemu-kvm.git. =9AThat patch can be used to work around this = issue by > >> >> >> using "-drive ...,boot=3Don" but it doesn't explain why the = RHEL 5.5 > >> >> >> kernel hangs during serial initialization when extboot is no= t present. > >> >> >> > >> >> > Hang that happens during guest boot (after bootloader started= the > >> >> > kernel) cannot be worked around by extboot. extboot is also n= ot needed > >> >> > with latest qemu git to boot from virtio disks since the supp= ort for > >> >> > that is in the bios now. > >> >> > >> >> I agree that something else is going on here and needs to be > >> >> investigated, but I do think that extboot can indirectly affect= the > >> >> guest boot. > >> >> > >> >> With extboot the virtio-blk PCI adapter is not touched by the > >> >> firmware/bootloader. =9AIs it possible that a virtio-blk interr= upt is > >> >> raised and not acknowledged before entering Linux. =9AWhen Linu= x brings > >> >> up the serial port it gets swamped with interrupts? =9AThat's j= ust a > >> >> guess. > >> >> > >> > That is possible when bios is actually used to boot the guest, b= ut bug > >> > reporter uses -kernel option so no bios boot code should run at = all. > >> > Virtio is initialized anyway, but this will happen with boot=3Do= n too. > >> > >> Okay, I got to the bottom of this. =9AHere's the story, see bottom= of the mail for > >> the solution and workarounds: > >> > > Great. Thanks Stefan. I was sure that fix you found is in qemu.git > > already. It is good to know that Linux actually uses int13 once. Di= dn't > > know that. To be absolutely sure no interrupt will stuck we should = probably > > clear interrupt after each virtio read in bios by reading status re= gister. >=20 > Yes, this is the approach I took when rewriting gPXE's virtio-net > driver recently: >=20 > http://git.etherboot.org/?p=3Dpeople/stefanha/gpxe.git;a=3Dblob;f=3Ds= rc/drivers/net/virtio-net.c;h=3D50c580049c3663f0d1332d51e30c8a59b5663b6= 8;hb=3Dd58bf6fc8db4a55075e370c7e1d436a570400f55#l299 >=20 > Are you spinning a patch or should I submit one? >=20 If you have time do it please. I am a little bit busy right now :( -- Gleb.