Xen project Mailing List

Re: [Xen-devel] [PATCH RFC V9 4/5] xen, libxc: Request page fault injection via libxc

> But ultimately, as Tim said, you're basically just *hoping* that it
> won't take too long to happen to be at the hypervisor when the proper
> condition happens. If the process in question isn't getting many
> interrupts, or is spending the vast majority of its time in the
> kernel, you may end up waiting an unbounded amount of time to be able
> to "catch" it in user mode. It seems like it would be better to find
> a reliable way to trap on the return into user mode, in which case you
> wouldn't need to have a special "wait for this complicated event to
> happen" call at all, would you?

Indeed, but it is assumed that the trap injection request is being made
by the caller in the proper context (when it knows that the condition
will be true sooner rather than later).

How is it known that the condition will be true soon? Some more information on what you consider 'proper context' would be valuable.

One solution I have used in the past is to just single-step the target application with MTF until it enters user-mode. It does have a heavy overhead when the target application is scheduled. Depending how often you need to catch the target process in usermode after a context-switch is what determines if this is a prohibitive performance overhead or not, in my case it was acceptable. An alternative I was contemplating is to look at the stack of the target application and inject an INT3 into the IP found in the trapframe. That approach has the least overhead as the trap really only triggers when the CPL just switched to user-mode. However it requires some OS specific knowledge to know what the trapframe on the stack looks like, which may require some level of trust in the guest kernel. Depending on the use case, it may also require some extra EPT protection to hide the presence of the trap from the OS or other in-guest code.. So there are alternatives already, it's just a question of how fast and how reliable they are.

Tamas

_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel