From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T44j5-0003Mv-A5 for qemu-devel@nongnu.org; Wed, 22 Aug 2012 02:47:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T44j1-0004q7-8g for qemu-devel@nongnu.org; Wed, 22 Aug 2012 02:47:39 -0400 Received: from mout.web.de ([212.227.17.12]:57677) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T44j0-0004q0-VZ for qemu-devel@nongnu.org; Wed, 22 Aug 2012 02:47:35 -0400 Message-ID: <5034807C.8010004@web.de> Date: Wed, 22 Aug 2012 08:47:24 +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> In-Reply-To: <20120822055725.GZ29724@truffula.fritz.box> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEB941738079B8979B1A0F8DB" 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: Alexander Graf , aliguori@us.ibm.com, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB941738079B8979B1A0F8DB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 t= o >>> write images into RAM - and will often be used that way if the machin= e >>> 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 we= >>> reset the firmware image was reloaded, but the TB from the rewrite wa= s >>> 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_phys= _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? >=20 > 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(). write_rom ignores write protection - that you usually find on ROMs. That 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. Jan --------------enigEB941738079B8979B1A0F8DB 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/ iEYEARECAAYFAlA0gIAACgkQitSsb3rl5xQn0QCfS3zG2HzMs8Yw5i4O21BHjJGA 4q0AoIhKq4lO54DBn998qB/KZmaDjU2A =AhrG -----END PGP SIGNATURE----- --------------enigEB941738079B8979B1A0F8DB--