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

[Anthony Liguori]

Jordan Justen <address@hidden> writes:

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

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.