From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4510-0005WT-7x for qemu-devel@nongnu.org; Wed, 22 Aug 2012 03:06:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T450v-0001UR-JX for qemu-devel@nongnu.org; Wed, 22 Aug 2012 03:06:10 -0400 Received: from mout.web.de ([212.227.17.11]:50680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T450v-0001UM-9b for qemu-devel@nongnu.org; Wed, 22 Aug 2012 03:06:05 -0400 Message-ID: <503484D0.6090100@web.de> Date: Wed, 22 Aug 2012 09:05:52 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1345611560-8290-1-git-send-email-david@gibson.dropbear.id.au> <48B2B165-8770-4BD9-9D9A-2D089A9A9208@suse.de> <20120822055725.GZ29724@truffula.fritz.box> <5034807C.8010004@web.de> In-Reply-To: <5034807C.8010004@web.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBF1AC52A5225031E3D8C2377" Subject: Re: [Qemu-devel] [PATCH] cpu_physical_memory_write_rom() needs to do TB invalidates List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: aliguori@us.ibm.com, Alexander Graf , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBF1AC52A5225031E3D8C2377 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-08-22 08:47, Jan Kiszka wrote: > On 2012-08-22 07:57, David Gibson wrote: >> On Wed, Aug 22, 2012 at 07:55:31AM +0200, Alexander Graf wrote: >>> >>> On 22.08.2012, at 06:59, David Gibson wrote: >>> >>>> cpu_physical_memory_write_rom(), despite the name, can also be used = to >>>> write images into RAM - and will often be used that way if the machi= ne >>>> uses load_image_targphys() into RAM addresses. >>>> >>>> However, cpu_physical_memory_write_rom(), unlike cpu_physical_memory= _rw() >>>> does invalidate any cached TBs which might be affected by the region= >>>> written. >>>> >>>> This was breaking reset (under full emu) on the pseries machine - we= loaded >>>> our firmware image into RAM, and while executing it rewrite the code= at >>>> the entry point (correctly causing a TB invalidate/refresh). When w= e >>>> reset the firmware image was reloaded, but the TB from the rewrite w= as >>>> still active and caused us to get an illegal instruction trap. >>>> >>>> This patch fixes the bug by duplicating the tb invalidate code from >>>> cpu_physical_memory_rw() in cpu_physical_memory_write_rom(). >>>> >>>> Signed-off-by: David Gibson >>>> --- >>>> exec.c | 7 +++++++ >>>> 1 file changed, 7 insertions(+) >>>> >>>> diff --git a/exec.c b/exec.c >>>> index 5834766..eff40d7 100644 >>>> --- a/exec.c >>>> +++ b/exec.c >>>> @@ -3523,6 +3523,13 @@ void cpu_physical_memory_write_rom(target_phy= s_addr_t addr, >>>> /* ROM/RAM case */ >>>> ptr =3D qemu_get_ram_ptr(addr1); >>>> memcpy(ptr, buf, l); >>>> + if (!cpu_physical_memory_is_dirty(addr1)) { >>>> + /* invalidate code */ >>>> + tb_invalidate_phys_page_range(addr1, addr1 + l, 0);= >>>> + /* set dirty bit */ >>>> + cpu_physical_memory_set_dirty_flags( >>>> + addr1, (0xff & ~CODE_DIRTY_FLAG)); >>>> + } >>> >>> Can't we just call cpu_physical_memory_rw in the RAM case? The >>> function only tries to not do MMIO accesses on ROM pages, right? >> >> Maybe. It's not clear at all to me what cases >> cpu_physical_memory_write_rom() is supposed to be for, as opposed to >> just using cpu_physical_memory_rw(). >=20 > write_rom ignores write protection - that you usually find on ROMs. Tha= t > makes no difference under KVM so far as there we lack read-only > sections. But that will be fixed soon, patches are on the list. In fact, it does make a difference also for KVM mode as cpu_physical_memory_rw works from userspace while the limitation only affects guest code running under KVM control. Jan PS: I'm still facing a bogus Mail-Followup-To tag in your postings, David, thus you easily fall from the To list on reply. --------------enigBF1AC52A5225031E3D8C2377 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/ iEYEARECAAYFAlA0hNAACgkQitSsb3rl5xSj6QCfQRoK1gMlteKTt0vpomY7sLxw 8/UAn32vJk+ifuHhx0wT/n/qxbAktDwE =vP2i -----END PGP SIGNATURE----- --------------enigBF1AC52A5225031E3D8C2377--