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

[Paolo Bonzini <pbonzini@redhat.com>]

Il 30/08/2013 14:10, Gleb Natapov ha scritto:
> On Fri, Aug 30, 2013 at 01:58:59PM +0200, Paolo Bonzini wrote:
>> 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.
>>
> Only when setting dirty/accessed bits, are they not set in ROM version
> of page tables?

They are set, but the hypervisor is using gfn_to_hva unconditionally.
See the patch I just posted.

Paolo