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

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

On 09/09/14 19:57, George Dunlap wrote:
> On Tue, Sep 2, 2014 at 2:24 PM, Tim Deegan <tim@xen.org> 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.
> 
> 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?

Are you talking about more complex mem_event-sending conditions? That's
certainly interesting. For now, we do have CR3 events, however waiting
for all CR3-change events is prohibitive in our case, because of the
frequent dom0 <-> HV switches incurred (which slow down the monitored
guest quite visibly).

> 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).


Thanks,
Razvan Cojocaru