[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.