[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] pflash: Restore & fix lazy ROMD switching

From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH] pflash: Restore & fix lazy ROMD switching
Date: Mon, 11 Apr 2011 07:27:38 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

On 2011-04-10 21:33, Jordan Justen wrote:
> On Sun, Apr 10, 2011 at 03:53, Jan Kiszka <address@hidden> wrote:
>> Commit 5145b3d1cc revealed a bug in the lazy ROMD switch-back logic, but
>> resolved it by breaking that feature. This approach addresses the issue
>> by switching back to ROMD after a certain amount of read accesses
>> without further unlock sequences.
> 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?
> 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.

> 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.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]