On Mon, Jan 28, 2013 at 12:48:43PM -0600, Anthony Liguori wrote:
> Gleb Natapov <g...@redhat.com> writes:
>
> > 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.
>
> 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.
