On Mon, Jan 28, 2013 at 10:10:06AM -0600, Anthony Liguori 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. > > 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. > The x86 emulator cannot fetch from MMIO memory today. And protected mode emulation is not so complete. We rarely, if ever, need to emulate protected mode instructions without memory operands.
> 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. Up until kernel 3.7 there was no support for read-only memory slots. As far as I know QEMU still maps ROM as regular RAM to KVM. > > SeaBIOS has hack to just not use PAM to do BIOS shadowing when running > under KVM/QEMU but presumably OVMF lacks this. Not sure that such hack exists and why is it needed. BIOS area is always writable in KVM. > > But in this case, you're using the flash device purely for read/write, > not for execution, so there's no limitation at all. > Yes, on newer kernel we can use read-only slots to emulate flash. They behaves like ROMD: memory on read MMIO on write. On older kernels we can use pure MMIO. -- Gleb.