From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46061 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pi4Bl-0000Eg-Hl for qemu-devel@nongnu.org; Wed, 26 Jan 2011 07:09:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pi4Bk-0000dQ-3y for qemu-devel@nongnu.org; Wed, 26 Jan 2011 07:09:29 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:44142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pi4Bj-0000cw-Fh for qemu-devel@nongnu.org; Wed, 26 Jan 2011 07:09:28 -0500 Message-ID: <4D400EF5.5090105@web.de> Date: Wed, 26 Jan 2011 13:09:25 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Errors on MMIO read access on VM suspend / resume operations References: <4D2C8305.2090609@linux.vnet.ibm.com> <4D2ED260.4010801@redhat.com> <4D30A38F.3030002@linux.vnet.ibm.com> <4D3303FD.8020509@redhat.com> <4D35030E.4080406@linux.vnet.ibm.com> <4D3554F4.6080405@siemens.com> <4D3DC49E.2000100@linux.vnet.ibm.com> <4D3DFE5A.802@web.de> <4D3E3FDE.80805@linux.vnet.ibm.com> <4D3E7B13.5000303@web.de> <4D3EFF01.9080608@linux.vnet.ibm.com> <4D3FD7ED.2000001@web.de> <4D400E1B.2020007@linux.vnet.ibm.com> In-Reply-To: <4D400E1B.2020007@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3D4F577942B638D03452141A" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger Cc: Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3D4F577942B638D03452141A Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2011-01-26 13:05, Stefan Berger wrote: > On 01/26/2011 03:14 AM, Jan Kiszka wrote: >> On 2011-01-25 17:49, Stefan Berger wrote: >>> On 01/25/2011 02:26 AM, Jan Kiszka wrote: >>>> Do you see a chance to look closer at the issue yourself? E.g. >>>> instrument the kernel's irqchip models and dump their states once yo= ur >>>> guest is stuck? >>> The device runs on iRQ 3. So I applied this patch here. >>> >>> diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c >>> index 3cece05..8f4f94c 100644 >>> --- a/arch/x86/kvm/i8259.c >>> +++ b/arch/x86/kvm/i8259.c >>> @@ -106,7 +106,7 @@ static inline int pic_set_irq1(struct kvm_kpic_st= ate >>> *s, int irq, int level) >>> { >>> int mask, ret =3D 1; >>> mask =3D 1<< irq; >>> - if (s->elcr& mask) /* level triggered */ >>> + if (s->elcr& mask) /* level triggered */ { >>> if (level) { >>> ret =3D !(s->irr& mask); >>> s->irr |=3D mask; >>> @@ -115,7 +115,10 @@ static inline int pic_set_irq1(struct >>> kvm_kpic_state *s, int irq, int level) >>> s->irr&=3D ~mask; >>> s->last_irr&=3D ~mask; >>> } >>> - else /* edge triggered */ >>> +if (irq =3D=3D 3) >>> + printk("%s %d: level=3D%d, irr =3D %x\n", __FUNCTION__,__LINE__,= level, >>> s->irr); >>> + } >>> + else /* edge triggered */ { >>> if (level) { >>> if ((s->last_irr& mask) =3D=3D 0) { >>> ret =3D !(s->irr& mask); >>> @@ -124,7 +127,9 @@ static inline int pic_set_irq1(struct kvm_kpic_st= ate >>> *s, int irq, int level) >>> s->last_irr |=3D mask; >>> } else >>> s->last_irr&=3D ~mask; >>> - >>> +if (irq =3D=3D 3) >>> + printk("%s %d: level=3D%d, irr =3D %x\n", __FUNCTION__,__LINE__,= level, >>> s->irr); >>> + } >>> return (s->imr& mask) ? -1 : ret; >>> } >>> >>> @@ -206,6 +211,8 @@ int kvm_pic_set_irq(void *opaque, int irq, int >>> level) >>> >>> pic_lock(s); >>> if (irq>=3D 0&& irq< PIC_NUM_PINS) { >>> +if (irq =3D=3D 3) >>> +printk("%s\n", __FUNCTION__); >>> ret =3D pic_set_irq1(&s->pics[irq>> 3], irq& 7, level);= >>> pic_update_irq(s); >>> trace_kvm_pic_set_irq(irq>> 3, irq& 7, s->pics[irq>> =20 >>> 3].elcr, >>> >>> >>> >>> While it's still working I see this here with the levels changing 0-1= -0. >>> Though then it stops and levels are only at '1'. >>> >>> [ 1773.833824] kvm_pic_set_irq >>> [ 1773.833827] pic_set_irq1 131: level=3D0, irr =3D 5b >>> [ 1773.834161] kvm_pic_set_irq >>> [ 1773.834163] pic_set_irq1 131: level=3D1, irr =3D 5b >>> [ 1773.834193] kvm_pic_set_irq >>> [ 1773.834195] pic_set_irq1 131: level=3D0, irr =3D 5b >>> [ 1773.835028] kvm_pic_set_irq >>> [ 1773.835031] pic_set_irq1 131: level=3D1, irr =3D 5b >>> [ 1773.835542] kvm_pic_set_irq >>> [ 1773.835545] pic_set_irq1 131: level=3D1, irr =3D 5b >>> [ 1773.889892] kvm_pic_set_irq >>> [ 1773.889894] pic_set_irq1 131: level=3D1, irr =3D 5b >>> [ 1791.258793] pic_set_irq1 119: level=3D1, irr =3D d9 >>> [ 1791.258824] pic_set_irq1 119: level=3D0, irr =3D d1 >>> [ 1791.402476] pic_set_irq1 119: level=3D1, irr =3D d9 >>> [ 1791.402534] pic_set_irq1 119: level=3D0, irr =3D d1 >>> [ 1791.402538] pic_set_irq1 119: level=3D1, irr =3D d9 >>> [...] >>> >>> >>> I believe the last 5 shown calls can be ignored. After that the >>> interrupts don't go through anymore. >>> >>> In the device model I see interrupts being raised and cleared. After = the >>> last one was cleared in 'my' device model, only interrupts are raised= =2E >>> This looks like as if the interrupt handler in the guest Linux was ne= ver >>> run, thus the IRQ is never cleared and we're stuck. >>> >> User space is responsible for both setting and clearing that line. IRQ= 3 >> means you are using some serial device model? Then you should check wh= at >> its state is. > Good hint. I moved it now to IRQ11 and it works fine now (with kvm-git)= > from what I can see. There was no UART on IRQ3 before, though, but > certainly it was the wrong IRQ for it. >> Moreover, a complete picture of the kernel/user space interaction shou= ld >> be obtainable by using fstrace for capturing kvm events. >> > Should it be working on IRQ3? If so, I'd look into it when I get a > chance... I don't know your customizations, so it's hard to tell if that should work or not. IRQ3 is intended to be used by ISA devices on the PC machine. Are you adding an ISA model, or what is your use case? Jan --------------enig3D4F577942B638D03452141A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ADvUACgkQitSsb3rl5xQeSgCg4CD+xtj01njfNwr2Rpy3rRbS fYwAn3bs0PLSgay64Sv9L2aFhgfO1jhq =Z+2h -----END PGP SIGNATURE----- --------------enig3D4F577942B638D03452141A--