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

[Anthony Liguori]

Gleb Natapov <address@hidden> writes:

> On Mon, Jan 28, 2013 at 10:10:06AM -0600, Anthony Liguori 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.
>> 
>> 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.

Ack.

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

Ack.

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

shadow.c:
  static void
  make_bios_writable_intel(u16 bdf, u32 pam0)
  {
      int reg = pci_config_readb(bdf, pam0);
      if (!(reg & 0x10)) {
          // QEMU doesn't fully implement the piix shadow capabilities -
          // if ram isn't backing the bios segment when shadowing is
          // disabled, the code itself wont be in memory.  So, run the
          // code from the high-memory flash location.

Normally when shadowing, you set the PAM registers to send read requests
to ROM and write requests to RAM.  You then read the code segment (that
you're executing from) and write that out to RAM and switch to executing
from there.

That's just not possible without treating ROMs as MMIO and sending all
requests down to QEMU.

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

Ack.

Regards,

Anthony Liguori

>
> --
>                       Gleb.