On Thu, Mar 10, 2011 at 10:59:07AM -0800, Jordan Justen wrote: > 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. 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.