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

[Gleb Natapov <gleb@redhat.com>]

On Thu, Mar 10, 2011 at 10:59:07AM -0800, Jordan Justen wrote:
> On Thu, Mar 10, 2011 at 01:47, Gleb Natapov <gleb@redhat.com> wrote:
> > Two things. First You suggest to replace -bios with -flash. This will
> > make firmware upgrade painful process that will have to be performed
> > from inside the guest since the same flash image will contain both
> > firmware and whatever data was stored on a flash which presumably you
> > want to reuse after upgrading a firmware.
> 
> Yes, this definitely could add firmware upgrade issues, but I thought
> this could be the responsibility of the firmware itself.  For example,
> OVMF could have an outside of VM tool to merge new releases, or it
> could have an inside of VM firmware update process.
Why require another tool if can do without? I don't see any advantages
in storing firmware code and its non-volatile storage in the same image,
but I do see disadvantages.

> 
> > My suggestion is to extend
> > -bios option like this:
> >
> > -bios bios.bin,flash=flash.bin,flash_base=addr
> >
> > flash.bin will be mapped at address flash_base, or, if flash_base is not
> > present, just below bios.bin.
> 
> I did not intend to replace -bios.  I intended to override -bios
> usage.  So, if -flash is not used, then it would operate as today.  If
> -flash is used, then it would override the -bios file.
> 
> So, for the firmware update issues mentioned above, it would not
> impact, say SeaBIOS...
> 
OVMF is not different from SeaBIOS as far as KVM/qemu is concerned. SeaBIOS
want to have non-volatile storage too.

> > 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.
> 
> I would be concerned about performance for KVM.  In my proposal, all
> reads would probably have to be treated as MMIO, since reads are
> involved in the programming sequences.
> 
> If the flash device was 1MB, and it was read entirely via MMIO
> trapping would there be a significant performance hit on KVM?  If so,
> I think I will have to consider a hybrid approach like you mentioned
> above, where most of the firmware is mapped as memory (copied from
> bios.bin), while a small amount of memory below this is available as
> flash.
> 
It is not even about performance (which will be very bad for 1MB). KVM
can't run code from MMIO region, so the part that contains firmware
has to be memory.

> But, in real systems, accessing the flash memory is significantly
> slower than RAM, so the real question is, how bad would the
> performance be?
> 
> Thanks,
> 
> -Jordan

--
			Gleb.