From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50995) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAS0N-000142-37 for qemu-devel@nongnu.org; Sun, 02 Oct 2011 15:47:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RAS0L-0003o7-KN for qemu-devel@nongnu.org; Sun, 02 Oct 2011 15:47:18 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:34975) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAS0L-0003nz-9r for qemu-devel@nongnu.org; Sun, 02 Oct 2011 15:47:17 -0400 Message-ID: <4E88BFBF.9040600@web.de> Date: Sun, 02 Oct 2011 21:47:11 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <40ebe424-6ad5-4b7f-acbb-b893fbf3b001@zmail04.collab.prod.int.phx2.redhat.com> In-Reply-To: <40ebe424-6ad5-4b7f-acbb-b893fbf3b001@zmail04.collab.prod.int.phx2.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3C743D43B1BB1F36E09A4A87" Sender: jan.kiszka@web.de Subject: Re: [Qemu-devel] [PATCH 11/22] i8259: Update IRQ state after reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Blue Swirl , Anthony Liguori , qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3C743D43B1BB1F36E09A4A87 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-10-02 21:07, Avi Kivity wrote: >>> >>> The way to fix it is two-phase reset: >>> >>> phase 1: reset internal state (-> move all outputs to reset >>> values), >>> don't sample inputs yet >>> phase 2: allow sampling inputs >> >> As far as I understood Anthony's QOM plans, phase 1 will correspond >> to >> "unrealize", phase 2 to "realize". >=20 > That smells of abusing mechanism used for construction for reset purpos= es. >=20 > Why not use an ordinary qemu_irq? It reresents a pin; 0->1 edge (asser= t) enters phase 1, 1->0 edge (deassert) enters phase 2. Exactly like rea= l hardware. QEMU makes no difference between power-on reset and system reset right now. At least I am not aware of any device model that has problems with this. Thus there is apparently no need to treat reset and create differently. As QOM requires a two-phase device creation anyway (to let properties to "settle"), it looks like there is some reuse potential. Jan --------------enig3C743D43B1BB1F36E09A4A87 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.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6Iv8IACgkQitSsb3rl5xQMfwCfc6C2dabCeTw9BD4oxS3Yspjz L+YAnRL49iLVSFk1wx0dLOfRPYbDx+NB =ZvAy -----END PGP SIGNATURE----- --------------enig3C743D43B1BB1F36E09A4A87--