As I'm working on bootrom loading support for omap/arm platform, I'm have suggestion about something more universal than -bios (and even -flash) option. Because Flash can be NOR, can be NAND, but on-chip memory is not flash memory. So may be something like -rom option?
Best regards, Anton Kochkov. On Thu, Mar 10, 2011 at 22:50, Jordan Justen <jljus...@gmail.com> wrote: > On Thu, Mar 10, 2011 at 11:12, Gleb Natapov <g...@redhat.com> wrote: >> On Thu, Mar 10, 2011 at 10:59:07AM -0800, Jordan Justen wrote: >>> 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. > > I agree. The implications of a firmware image getting out of sync > with qemu were a bit of a concern to me. But, having both -bios + > -flash just below -bios was starting to seem a bit complicated. > > And, I guess as a firmware developer, I thought it might be > interesting to consider enabling a firmware update process within the > VM. :) > > How about? > 1) Pure rom: > -bios bios.bin > 2) Rom + flash below rom: > -bios bios.bin,flash=flash.bin > 3) Pure flash: > -bios flash=flash.bin > > Or, with a separate new -flash option: > 1) Pure rom: > -bios bios.bin > or no -bios or -flash parameters > 2) Rom + flash below rom: > -bios bios.bin -flash flash.bin > 3) Pure flash: > -flash flash.bin > >> 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. > > Hmm. That's good to know. :) > > So, perhaps this feature should build upon the other feature you and > Jan are discussing. When will it become available? > > Thanks, > > -Jordan > >