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

[Tim Deegan <tim@xxxxxxx>]

At 17:57 +0100 on 09 Sep (1410281829), George Dunlap wrote:
> On Tue, Sep 2, 2014 at 2:24 PM, Tim Deegan <tim@xxxxxxx> wrote:
> > Hi,
> >
> > At 12:18 +0300 on 02 Sep (1409656686), Razvan Cojocaru wrote:
> >> While we need to set the data per-domain and have whatever VCPU inject
> >> the page fault - _but_only_if_ it's in usermode and its CR3 points to
> >> something interesting.
> >
> > That's a strange and specific thing to ask the hypervisor to do for
> > you.  Given that you can already trap CR3 changes as mem-events can
> > you trigger the fault injection in response to the contect switch?
> > I guess that would probably catch it in kernel mode. :(
> 
> I was wondering, rather than special-casing inject_trap, would it make
> sense to be able for the memory controller to get notifications when
> certain more complex conditions happen (e.g., "some vcpu is in user
> mode with this CR3")?  Then the controller could ask to be notified
> when the event happens, and when it does, just call inject_fault.

Yes, that sounds like a better place to put this kind of test.  As
part of the mem_event trigger framework it doesn't seem nearly so out
of place (and it avoids many of the problems of clashes between
different event injection paths).

> That way, inject_fault isn't special-cased at all; and one could
> imagine designing the "condition" such that any number of interesting
> conditions could be trapped.
> 
> Thoughts?
> 
> 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?

Yeah; I was thinking about page-protecting the process's stack as an
approach to this.  Breakpointing the return address might work too but
would probably cause more false alarms -- you'd at least need to walk
up past the libc/win32 wrappers to avoid trapping every thread.

Ideally there'd be something vcpu-specific we could tinker with
(e.g. arranging MSRs so that SYSRET will fault) once we see the right
CR3 (assuming intercepting CR3 is cheap enough in this case).

Tim.

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