From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44723 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCex1-00066i-N4 for qemu-devel@nongnu.org; Thu, 13 May 2010 16:24:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCewz-00026Q-Sk for qemu-devel@nongnu.org; Thu, 13 May 2010 16:24:11 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:49235) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCewz-00026D-HC for qemu-devel@nongnu.org; Thu, 13 May 2010 16:24:09 -0400 Message-ID: <4BEC5FE3.6080806@web.de> Date: Thu, 13 May 2010 22:24:03 +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> <4BEC5CC7.4010200@web.de> In-Reply-To: <4BEC5CC7.4010200@web.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1C32FF26405A4501BBDB3B3F" 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) --------------enig1C32FF26405A4501BBDB3B3F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Jamie Lokier wrote: >> Jan Kiszka wrote: >>> While IO_MEM_ROMD marks an I/O memory region as "read/execute from RA= M, >>> 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. >> I like this change. >> >> Does "fetching opcodes while still in I/O device mode" fetch opcodes >> from the RAM backing, or via the I/O read handlers? >=20 > 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. >=20 > 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. Which, of course, would break CFI reads etc. for KVM guest. So this feature actually requires additional support by KVM to fetch code from I/O devices. Jan --------------enig1C32FF26405A4501BBDB3B3F 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 iEYEARECAAYFAkvsX+YACgkQitSsb3rl5xQMzwCgwfj0Bb2m4tQ3FEpd6Hosk27U DLsAmQGgmtSWM913Wh6aVijjc08LLTne =GtBU -----END PGP SIGNATURE----- --------------enig1C32FF26405A4501BBDB3B3F--