On Thu, Mar 10, 2011 at 01:47, Gleb Natapov <g...@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. > 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... > 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. 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