From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60081) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFNXR-0003cb-SX for qemu-devel@nongnu.org; Fri, 30 Aug 2013 08:10:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VFNXN-00088h-3n for qemu-devel@nongnu.org; Fri, 30 Aug 2013 08:10:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFNXM-00088K-SJ for qemu-devel@nongnu.org; Fri, 30 Aug 2013 08:10:49 -0400 Date: Fri, 30 Aug 2013 15:10:38 +0300 From: Gleb Natapov Message-ID: <20130830121038.GC1844@redhat.com> References: <20130828103552.GC2038@GaryOffice.site> <521DE2EB.9050404@redhat.com> <521DE3C0.4030603@suse.de> <521DE8C7.1010903@redhat.com> <521DF33E.4090205@suse.de> <20130829082317.GA1852@GaryOffice.site> <521F1CB802000048000E30E0@suse.com> <20130830032828.GA1713@GaryOffice.site> <522067C7.4090606@redhat.com> <52208903.4000706@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52208903.4000706@redhat.com> Subject: Re: [Qemu-devel] [edk2] OVMF hung on qemu 1.6.0 with KVM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: edk2-devel@lists.sourceforge.net, "qemu-devel@nongnu.org" , Alexander Graf , Gary Ching-Pang Lin , Ludwig Nussel , Bruce Rogers , Laszlo Ersek , afaerber@suse.de 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 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 -- Gleb.