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

[Gleb Natapov]

On Mon, Jan 28, 2013 at 12:48:43PM -0600, Anthony Liguori wrote:
> 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.
> 
Ack.

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

--
                        Gleb.