qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: RFC: emulation of system flash


From: Carl-Daniel Hailfinger
Subject: Re: [Qemu-devel] Re: RFC: emulation of system flash
Date: Thu, 10 Mar 2011 22:41:56 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.16) Gecko/20101124 SUSE/2.0.11-0.2.1 SeaMonkey/2.0.11

Auf 10.03.2011 12:48, Gleb Natapov schrieb:
> On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote:
>   
>> On 2011-03-10 10:47, Gleb Natapov wrote:
>>     
>>> Second. I asked how flash is programmed because interfaces like CFI
>>> where you write into flash memory address range to issue commands cannot
>>> be emulated efficiently in KVM. KVM supports either regular memory slots
>>> or IO memory, but in your proposal the same memory behaves as IO on
>>> write and regular memory on read. Better idea would be to present
>>> non-volatile flash as ISA virtio device. Should be simple to implement.
>>>       
>> Why not enhancing KVM memory slots to support direct read access while
>> writes are trapped and forwarded to a user space device model?
>>     
> Yes we can make memory slot that will be treated as memory on read and
> IO on write, but first relying on that will prevent using flash interface
> on older kernels and second it is not enough to implement the proposal.
> When magic value is written into an address, the address become IO for
> reading too, but KVM slot granularity is page, not byte, so KVM will
> have to remove the slot to make it IO, but KVM can't execute code from
> IO region (yet), so we will not be able to run firmware from flash and
> simultaneously write into the flash.
>   

If you have a Parallel/LPC/FWH flash chip in your mainboard, it is
technically impossible to execute code from flash while you are writing
to _any_ part of the flash chip because every single read from the flash
chip during an active write will toggle one bit of the read data.
So if your code already runs on real x86, you will never hit that problem.

(SPI flash is an exception, but it uses out-of-band access anyway,
usually via some southbridge interface, and that means the IO vs.
execution conflict won't happen there either.)

Regards,
Carl-Daniel

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




reply via email to

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