From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38639 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q99fH-0007rE-Rh for qemu-devel@nongnu.org; Mon, 11 Apr 2011 01:27:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q99fG-0002Wo-Qy for qemu-devel@nongnu.org; Mon, 11 Apr 2011 01:27:55 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:50518) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q99fG-0002WY-GN for qemu-devel@nongnu.org; Mon, 11 Apr 2011 01:27:54 -0400 Message-ID: <4DA2914A.4070203@web.de> Date: Mon, 11 Apr 2011 07:27:38 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] pflash: Restore & fix lazy ROMD switching References: <1301861786-6637-1-git-send-email-jordan.l.justen@intel.com> <4DA16C6A.7090303@web.de> <4DA18C33.6050002@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig213B3674BD0489D46FB4157D" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jordan Justen Cc: qemu-devel@nongnu.org, Aurelien Jarno This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig213B3674BD0489D46FB4157D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-04-10 21:33, Jordan Justen wrote: > On Sun, Apr 10, 2011 at 03:53, Jan Kiszka wrote: >> Commit 5145b3d1cc revealed a bug in the lazy ROMD switch-back logic, b= ut >> resolved it by breaking that feature. This approach addresses the issu= e >> by switching back to ROMD after a certain amount of read accesses >> without further unlock sequences. >=20 > Without this change, the code will stay in flash mode until a single > read occurs. The code sequence you are wanting to support using will > issue a read before trying to unlock again? >=20 > Actually, I suppose it will want to verify the written data before > moving on, so this does make sense. Precisely. The drivers (e.g. Linux) compare two successive reads for bit flips. In their absence, the result was written. The guest I'm optimizing for does 5 reads per write. >=20 > Is the overhead of switching the modes significant enough to justify > the lazy switch-back? (If so, maybe I'll look at this for cfi01 too.) As we call into cpu_register_physical_memory, the overhead is tremendous, an order of magnitude IIRC, which will sum up to huge delays when reflashing a complete multi-MB firmware image e.g. Jan --------------enig213B3674BD0489D46FB4157D 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.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk2ikU0ACgkQitSsb3rl5xQeaACfRAdOZD/OteBrABJbgqrIesOo nf4AoJ8VUACX84Q8KK0wGGSijBBK6sR7 =xcMD -----END PGP SIGNATURE----- --------------enig213B3674BD0489D46FB4157D--