From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60000 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCekD-000291-FQ for qemu-devel@nongnu.org; Thu, 13 May 2010 16:10:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCekB-0000ZQ-N7 for qemu-devel@nongnu.org; Thu, 13 May 2010 16:10:57 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:56286) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCekB-0000ZB-Ay for qemu-devel@nongnu.org; Thu, 13 May 2010 16:10:55 -0400 Message-ID: <4BEC5CC7.4010200@web.de> Date: Thu, 13 May 2010 22:10:47 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/4] Add support for execution from ROMs in IO device mode References: <5b7efeb30fe6f93a369b6a9f964a2cb7c0519222.1273760202.git.jan.kiszka@web.de> <20100513192324.GA9388@shareable.org> In-Reply-To: <20100513192324.GA9388@shareable.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA24EBB1F110E916D5AE194D1" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Michael Walle , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA24EBB1F110E916D5AE194D1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jamie Lokier wrote: > Jan Kiszka wrote: >> While IO_MEM_ROMD marks an I/O memory region as "read/execute from RAM= , >> but write to I/O handler", there is no flag indicating that an I/O >> region which is fully managed by I/O handlers can still be hosting >> executable code. One use case for this are flash device models that >> switch to I/O mode during reprogramming. Not all reprogramming states >> modify to read data, thus practically allow to continue execution. >> Moreover, we need to avoid switching the modes too frequently for >> performance reasons which requires fetching opcodes while still in I/O= >> device mode. >=20 > I like this change. >=20 > Does "fetching opcodes while still in I/O device mode" fetch opcodes > from the RAM backing, or via the I/O read handlers? Via the latter. This is most "correct" in that broken guests that jump to the ROM while it's in some critical write cycle will properly crash. >=20 > If the latter, I'm wondering how KVM would cope with that. I think it won't work without extending KVM to fetch - as a last resort - also from I/O devices. Or we give up the "correctness" and keep the RAM-base KVM slot for IO_MEM_EXEC regions. That should be solvable in a transparent way in kvm_set_phys_mem. Jan --------------enigA24EBB1F110E916D5AE194D1 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.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkvsXMwACgkQitSsb3rl5xR9uQCg16L9y+3yaByupfO3ISaklB6x Q1AAn0z4eloBybxVCA+jTmxC4HKlHwjX =K2v6 -----END PGP SIGNATURE----- --------------enigA24EBB1F110E916D5AE194D1--