On 09/03/13 15:41, Laszlo Ersek wrote:
> qemu-system-x86-29149 [002] 12270.790112: kvm_exit: reason
> EXIT_WRITE_CR0 rip 0xffffff23 info 0 0
> qemu-system-x86-29149 [002] 12270.790113: kvm_emulate_insn: 0:ffffff23:
> 0f 22 c0
> qemu-system-x86-29149 [002] 12270.790121: kvm_entry: vcpu 0
> qemu-system-x86-29149 [002] 12270.790124: kvm_exit: reason
> EXIT_NPF rip 0xffffff26 info 200000007 ffffe000
> qemu-system-x86-29149 [002] 12270.790125: kvm_page_fault: address
> ffffe000 error_code 7
> qemu-system-x86-29149 [002] 12270.790129: kvm_emulate_insn: 0:ffffff26:
> 0f 22 c0
> qemu-system-x86-29149 [002] 12270.790131: kvm_emulate_insn: 0:ffffff26:
> 0f 22 c0 FAIL
> qemu-system-x86-29149 [002] 12270.790134: kvm_userspace_exit: reason
> KVM_EXIT_INTERNAL_ERROR (17)
> qemu-system-x86-29149 [002] 12270.790137: kvm_fpu: unload
Actually, the mov-to-cr0 seems to succeed, and the subsequent
ljmp $0x18,$0xffffff2d
causes an EXIT_NPF. The SVM reference manual says,
Nested paging: host-level page fault occurred. EXITINFO1
contains fault errorcode. EXITINFO2 contains the guest
physical address causing the fault.
The "0f 22 c0" instruction bytes reported under EXIT_NPF are probably
wrong (a mis-trace). The EXIT_NPF could occur immediately after the
guest enables paging (with the mov-to-cr), no?
... This problem seems to be rooted in the same read-only-memslot thing
that we recently encountered on an Intel host that lacks EPT: the SVM
reference manual also says, under 2.20.3 Permission Checks:
When nested paging is enabled, pages accessed by the guest must be
marked as present and accessible at the user-level in the host page
table---regardless of the current guest CPL. Further, the host mapping
must permit writes for the guest to be able to write the page. A
failed host access check (for an access that is otherwise legal at the
guest level) results in a #VMEXIT(NPF).
Note: Host permissions are checked on every reference to a guest
physical address---even those caused by guest page table walks.
In particular, when attempting to set an "Accessed" or "Dirty"
bit while walking the guest tables (which reside in guest
physical space), the processor checks whether the corresponding
host virtual page is present and user-level writable; if not,
the processor raises a #VMEXIT(NPF).
Since OVMF has the initial page tables in ROM, the above won't fly.
I'll try two workarounds (the same two that came up in the EPT thread):
- reverting the qemu commit that enables the r/o mapping,
- applying Jordan's experimental patches for OVMF that build the initial
page tables in RAM, as early as in the reset vector code.
Thanks
Laszlo
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
