Jordan Justen <jljus...@gmail.com> writes: > On Mon, Jan 28, 2013 at 8:10 AM, Anthony Liguori <anth...@codemonkey.ws> > wrote: >> David Woodhouse <dw...@infradead.org> writes: >> >>> On Sun, 2013-01-27 at 18:53 -0600, Anthony Liguori wrote: >>>> Are you just trying to persist a single blob of a fixed maximum size? >>> >>> That would suffice. >>> >>>> Why not just have a second flash device then? >>> >>> Mostly because flash devices don't actually *work* with KVM. >> >> They absolutely do. What doesn't work is executing ROM from flash if >> the ROM cannot be treated as read-only memory. > > What is need is for pflash_cfi01 to start in plain rom/executable mode > while firmware executes from it during early boot. > > Then later, after the rom has been shadowed, firmware will want to > write to that memory space to program it. At that point it no longer > needs to be executable. > > So the question is, can it start out in rom/executable mode, but > change into a non-executable mode if a write occurs?
It's a matter of how you setup the memory region but yes, I see no problem with this although it may need to be a qdev option. > chance to respond if something is written to a rom region, or is it > silently ignored? > > Also, once the 'read-array' command is written to it after programming > is finished, can it revert to executable rom mode? Reverting to executable means remapping the region as read-only memory verses MMIO. So yes, it's technically possible. I suspect that you want to make this behavior a flag for the device though. Regards, Anthony Liguori > > -Jordan > >> That's because all we get is a PF in the kernel when trying to execute >> from unmapped ROM. There's no way to turn that into MMIO to userspace >> without switching to running fully in emulation mode. The x86 emulator >> is pretty close to complete but work would be needed to fully complete >> it to make this work. >> >> We normally handle this by mapping the ROM memory read-only so it can be >> executed without PF'ing but since the BIOS area is subject to PAM, we >> can't use this trick for that particular ROM. >> >> SeaBIOS has hack to just not use PAM to do BIOS shadowing when running >> under KVM/QEMU but presumably OVMF lacks this. >> >> But in this case, you're using the flash device purely for read/write, >> not for execution, so there's no limitation at all.
