From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFSZU-00017j-4B for qemu-devel@nongnu.org; Fri, 30 Aug 2013 13:33:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VFSZS-0002dR-FP for qemu-devel@nongnu.org; Fri, 30 Aug 2013 13:33:20 -0400 Received: from mail-ie0-x22f.google.com ([2607:f8b0:4001:c03::22f]:49670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFSZS-0002bk-9i for qemu-devel@nongnu.org; Fri, 30 Aug 2013 13:33:18 -0400 Received: by mail-ie0-f175.google.com with SMTP id u16so3883866iet.34 for ; Fri, 30 Aug 2013 10:33:17 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <5220931A.9050608@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> <20130830121038.GC1844@redhat.com> <5220931A.9050608@redhat.com> Date: Fri, 30 Aug 2013 10:33:17 -0700 Message-ID: From: Jordan Justen Content-Type: text/plain; charset=ISO-8859-1 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: "edk2-devel@lists.sourceforge.net" Cc: Gleb Natapov , "qemu-devel@nongnu.org" , Alexander Graf , Bruce Rogers , Ludwig Nussel , afaerber@suse.de On Fri, Aug 30, 2013 at 5:42 AM, Paolo Bonzini wrote: > 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. We should be building the tables in ROM such that they are marked as present, accessed and dirty. Thus, the processor should never want to write to them. My first pass 'fix' to this was to transition the tables to RAM very early, but I think they ought to have worked from the ROM. (I just assumed we were dealing with some KVM limitation, or was it a KVM bug?) -Jordan