From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFO5I-0001rb-AQ for qemu-devel@nongnu.org; Fri, 30 Aug 2013 08:45:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VFO5D-0005vp-5C for qemu-devel@nongnu.org; Fri, 30 Aug 2013 08:45:52 -0400 Received: from mail-ea0-x235.google.com ([2a00:1450:4013:c01::235]:37108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFO1h-0004kd-R3 for qemu-devel@nongnu.org; Fri, 30 Aug 2013 08:42:09 -0400 Received: by mail-ea0-f181.google.com with SMTP id d10so882571eaj.26 for ; Fri, 30 Aug 2013 05:42:09 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5220931A.9050608@redhat.com> Date: Fri, 30 Aug 2013 14:42:02 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> <20130830121038.GC1844@redhat.com> In-Reply-To: <20130830121038.GC1844@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Gleb Natapov Cc: Alexander Graf , edk2-devel@lists.sourceforge.net, "qemu-devel@nongnu.org" , Bruce Rogers , Gary Ching-Pang Lin , Ludwig Nussel , Laszlo Ersek , afaerber@suse.de 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