Re: [Qemu-devel] [edk2] OVMF hung on qemu 1.6.0 with KVM

[Paolo Bonzini <pbonzini@redhat.com>]

Il 30/08/2013 11:37, Laszlo Ersek ha scritto:
> Disclaimer: I don't know what I'm talking about.

No problem. :)

> So, Jordan's patch for OVMF (SVN r14494) builds the page tables (and
> finally writes the root to CR3) in a phase when paging is not enabled
> yet in the VM.
> 
> Again, I have no clue, but if the guest hasn't even enabled paging yet,
> then the hypervisor (without EPT?) might have no idea that what the
> guest is writing to memory are its pagetables-to-be. The first notice
> the hypervisor might take is the store to CR3. At which point (or maybe
> even later, when paging is enabled?) the hypervisor would have to walk
> the guest's tables all at once, and build the shadow tables "in batch".

The hypervisor builds shadow page tables lazily; as soon as CR0.PG is
set the next instruction will pagefault and shadow page tables will
start to get populated.

However, surprise!  There is another set of "flat" page tables for X64,
built by UefiCpuPkg/ResetVector/Vtf0/Tools/FixupForRawSection.py when
you run UefiCpuPkg/ResetVector/Vtf0/Build.py.  These are always in ROM.

As in Jordan's patches, the problem is that the hypervisor is expecting
to be able to write to the page tables, but this is not the case because
the page tables are in a read-only memory slot.

Making shadow and EPT behave similarly is probably a good thing, so I'm
sending an RFC patch to kvm@vger.kernel.org that fixes the bug.

However, if you guys can figure out a patch for
UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm so that it builds
the page tables in RAM (and removing the page table Python code), that
would also work.

Paolo