From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=43303 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Pxnfs-0007Qu-PM
	for qemu-devel@nongnu.org; Thu, 10 Mar 2011 16:45:37 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <c-d.hailfinger.devel.2006@gmx.net>)
	id 1Pxnfr-0000R4-7d
	for qemu-devel@nongnu.org; Thu, 10 Mar 2011 16:45:36 -0500
Received: from mailout-de.gmx.net ([213.165.64.22]:39235)
	by eggs.gnu.org with smtp (Exim 4.71)
	(envelope-from <c-d.hailfinger.devel.2006@gmx.net>)
	id 1Pxnfq-0000Qy-SA
	for qemu-devel@nongnu.org; Thu, 10 Mar 2011 16:45:35 -0500
Message-ID: <4D7946BA.2040704@gmx.net>
Date: Thu, 10 Mar 2011 22:46:34 +0100
From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: RFC: emulation of system flash
References: <AANLkTik3tjjsbn9RuGC1MOq_eZB22aAUDsKuq7MBy=rf@mail.gmail.com>	<20110310094726.GB14805@redhat.com>
	<4D78B5BB.5020408@siemens.com>	<20110310114801.GC14805@redhat.com>
	<4D78BEB6.6070208@siemens.com>
In-Reply-To: <4D78BEB6.6070208@siemens.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Gleb Natapov <gleb@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel <qemu-devel@nongnu.org>, Michal Suchanek <hramrach@centrum.cz>, Kevin O'Connor <kevin@koconnor.net>, Avi Kivity <avi@redhat.com>, Jordan Justen <jljusten@gmail.com>

Auf 10.03.2011 13:06, Jan Kiszka schrieb:
> BTW, the programming granularity is not bytes but chips with common CFI.
> But that's still tricky if you want to run code from the same chip while
> updating parts of it. The easiest workaround would be handling the
> overlay regions as ROM all the time. Not accurate but realizable without
> kernel changes.
>   

I've yet to see CFI chips on x86.


>> On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
>>     
>>> Virtio
>>> means that you have to patch the guest (which might be something else
>>> than flexible Linux...).
>>>
>>>       
>> This intended to be used by firmware only and we control that.
>>     
> I'm thinking beyond this use case, beyond firmware flashes, beyond x86.
>   

If you're thinking beyond x86, most flash is probably using SPI nowadays
because the reduced PCB footprint can save lots of money. And for SPI
you only need OOB access for write and the memory region itself is readonly.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/