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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 10/09/14 09:55, Razvan Cojocaru wrote:
> On 09/10/2014 11:48 AM, Andrew Cooper wrote:
>> On 10/09/2014 09:09, Razvan Cojocaru wrote:
>>> On 09/09/2014 09:38 PM, Tamas K Lengyel wrote:
>>>>     > 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.
>>> It's actually pretty simple for us: the application always requests an
>>> injection when the guest is already in the address space of the
>>> interesting application, and in user mode.
>> Does this mean that you always request a pagefault as a direct result of
>> a mem_event, when the vcpu is in blocked the correct context?
> Yes, exactly.
>
>> If so, how about extending the mem_event response mechanism with
>> trap/fault information?
> For this particular case, that is indeed a very good suggestion -
> however, things may change. From what I understand, it is likely that in
> the future we (or somebody else doing memory introspection) will need to
> request a page fault injection in other cases. The risks described above
> will of course exist in that case, but they are acceptable.

Right.  I can see your concern, but designing an interface like this for
some hopeful future can be problematic, especially given only a vague
idea of how it would be used in practice.

With the Xen hypercall API/ABI, it is always possible to add something
in the future, and a concrete example of how it is suppose to work does
greatly help with justifying its design and implementation.

In this case, I feel that extending mem_event responses is a very
natural thing to do.  It very closely ties the pagefault to the action
which resulted in the decision for a pagefault, rather than an
apparently asynchronous pagefault request via another mechanism which
userspace has to use when it knows that the vcpu is blocked on a mem_event.

Furthermore, having a general "please inject a fault which looks like
this" mechanism allows the mem_event userspace agent algorithm to choose
to inject other faults for different circumstances.

~Andrew