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?
> Making shadow and EPT behave similarly is probably a good thing, so I'm
> sending an RFC patch to k...@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
--
Gleb.
