From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33726 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pi0Wy-0003g5-Re for qemu-devel@nongnu.org; Wed, 26 Jan 2011 03:15:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pi0Wx-00034R-KE for qemu-devel@nongnu.org; Wed, 26 Jan 2011 03:15:08 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:54251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pi0Wx-000340-4V for qemu-devel@nongnu.org; Wed, 26 Jan 2011 03:15:07 -0500 Message-ID: <4D3FD7ED.2000001@web.de> Date: Wed, 26 Jan 2011 09:14:37 +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> In-Reply-To: <4D3EFF01.9080608@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8A592A8F9B12418450AF53CA" 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) --------------enig8A592A8F9B12418450AF53CA Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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 your= >> guest is stuck? > The device runs on iRQ 3. So I applied this patch here. >=20 > 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_stat= e > *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__,le= vel, > 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_stat= e > *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__,le= vel, > s->irr); > + } > return (s->imr& mask) ? -1 : ret; > } >=20 > @@ -206,6 +211,8 @@ int kvm_pic_set_irq(void *opaque, int irq, int leve= l) >=20 > 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>> 3].elc= r, >=20 >=20 >=20 > While it's still working I see this here with the levels changing 0-1-0= =2E > Though then it stops and levels are only at '1'. >=20 > [ 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 > [...] >=20 >=20 > I believe the last 5 shown calls can be ignored. After that the > interrupts don't go through anymore. >=20 > In the device model I see interrupts being raised and cleared. After th= e > last one was cleared in 'my' device model, only interrupts are raised. > This looks like as if the interrupt handler in the guest Linux was neve= r > run, thus the IRQ is never cleared and we're stuck. >=20 User space is responsible for both setting and clearing that line. IRQ3 means you are using some serial device model? Then you should check what its state is. Moreover, a complete picture of the kernel/user space interaction should be obtainable by using fstrace for capturing kvm events. Jan --------------enig8A592A8F9B12418450AF53CA 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/ iEYEARECAAYFAk0/1+0ACgkQitSsb3rl5xSsjwCgvqs7dBGGWjwler0L7iHkk95x DW4AnjP1YU5QG6ui9Apja+1XNCgTtIoj =XKDa -----END PGP SIGNATURE----- --------------enig8A592A8F9B12418450AF53CA--