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: Mon, 5 Jul 2010 15:41:12 +0300 Message-ID: <20100705124112.GR4689@redhat.com> References: <1278041518.10459.48.camel@geektop> <20100705121759.GP4689@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: ewheeler , kvm@vger.kernel.org To: Stefan Hajnoczi Return-path: Received: from mx1.redhat.com ([209.132.183.28]:15791 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758615Ab0GEMlP convert rfc822-to-8bit (ORCPT ); Mon, 5 Jul 2010 08:41:15 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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 wrote: > >> On Fri, Jul 2, 2010 at 9:07 AM, Stefan Hajnoczi wrote: > >> > On Fri, Jul 2, 2010 at 4:31 AM, ewheeler w= rote: > >> >> 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 no= t when > >> >> drive if=3Dide. =9ALook close---this is not a "forgot to add vi= rtio_blk" > >> >> problem. =9AIf I use 0.12.3 from Ubuntu 10.04 it works properly= =2E > >> >> > >> >> Reproduction: > >> >> > >> >> Using kvm 0.12.3 on ubuntu 10.04 (1:84+dfsg-0ubuntu16+0.12.3+no= roms > >> >> +0ubuntu9) it will work properly: > >> >> > >> >> =9Aqemu-system-x86_64 -drive file=3Ddummy-disk-image,if=3Dvirti= o \ > >> >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A-kernel vmlinuz-= 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 bytes. > >> >> > >> >> ---However---if I use today's git (2010-07-01) of kvm: > >> >> > >> >> =9A /usr/local/kvm-git/bin/qemu-system-x86_64 -drive file=3Ddum= my-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 (obtained = by adding > >> >> -serial stdio -append console=3DttyS0): > >> >> > >> >> Note that this only happens with the disk interface set to virt= io > >> >> (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 you desc= ribed > >> > with the RHEL 5.5 kernel. =9AI have not investigated. > >> > >> This issue is affected by extboot, a feature that enables booting = from > >> virtio-blk devices. =9AI have just sent a patch to the KVM mailing= 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= =2E5 > >> kernel hangs during serial initialization when extboot is not pres= ent. > >> > > Hang that happens during guest boot (after bootloader started the > > kernel) cannot be worked around by extboot. extboot is also not nee= ded > > with latest qemu git to boot from virtio disks since the support fo= r > > that is in the bios now. >=20 > 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. >=20 > With extboot the virtio-blk PCI adapter is not touched by the > firmware/bootloader. Is it possible that a virtio-blk interrupt is > raised and not acknowledged before entering Linux. When Linux brings > up the serial port it gets swamped with interrupts? That's just a > guess. >=20 That is possible when bios is actually used to boot the guest, but bug reporter uses -kernel option so no bios boot code should run at all. Virtio is initialized anyway, but this will happen with boot=3Don too. > Newer (non-RHEL 5.5) kernels boot fine without extboot, so another > path to solving this bug is to bisect guest kernels. >=20 > Stefan -- Gleb.