[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] X86 emulation under HAP/EPT
At 16:42 -0800 on 06 Dec (1323189750), Shriram Rajagopalan wrote: > Log-dirty allows me to log only one write access. In order to log > multiple read/write accesses, > I resorted to *emulating* the instructions that cause the page fault. > (I guess I could also play around with the trap flags & single > stepping the guest, but thats a last resort). Sure. Single-stepping would require you to pause all other vcpus for safety. While that might or might not be slower than emulating, it's hard to do without deadlocking. :) > I can see that the vmx_vmexit_handler does some emulation for select > operations (e.g., msr) > So, I assume that when the code faults with EXIT_REASON_EPT_VIOLATION > and jumps into > hvm.c:hvm_hap_nested_page_fault(), it is either due to MMIO/PoD/LogDirty It's because of a vioation of the right in the EPT table; so any of those, or the newe mem_access/vm-paging/memory-sharing mechanisms (but only if you enable them), or if the guest just accesses memory that isn't there. :) > Is it right to assume that when the EPT_VIOLATION fault occurs, the > instruction in question > intends to do only simple reads/writes to the page? No MSRs, rdtscs, > cr3 switches, etc, All you know is that the CPU is accessing the page. The instruction under %rip could be anything at all, if an interrupt arrived and the stack pointer crossed into a new page while writing the stack frame. Even if it is a plain memory access, it could be using a vector instruction that's not supprted by the emulator. > When I enable the log dirty mode, I see a bunch of emulation failures > with exception code > X86EMUL_UNHANDLEABLE and then a vm-entry failure saying invalid guest state. [...] > Any pointers on how to resolve this issue? I'd start by printing the bytes under %rip when you see X86EMUL_UNHANDLEABLE, which will tell you what instruciton is failing. That will help you track down _why_ it's failing. The Intel manuals have a long list of the state checks that can cause this VMENTER failure; I don't think there's currently code in the tree to figure out which it is, but if you do end up writing it a patch would be welcome. :) Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |