Re: [Qemu-devel] [RFC] Writeable files in fw_cfg

[Jordan Justen]

On Mon, Jan 28, 2013 at 8:10 AM, Anthony Liguori <address@hidden> wrote:
> David Woodhouse <address@hidden> 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? Will qemu get a
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?

-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.