[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 09/10/14 13:39, George Dunlap wrote:
> On Wed, Sep 10, 2014 at 9:55 AM, Razvan Cojocaru
> <rcojocaru@xxxxxxxxxxxxxxx> 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.
> 
> Sorry -- do you mean that you don't actually need this functionality
> right now, but you think that maybe someone else might need it, or you
> may need it in the future?  That doesn't sound very promising; at the
> moment it sounds like you're not actually even testing this mechanism
> to make sure that it works the way you hope it does.

No. The functionality _is_ being tested, but currently it's only being
used in the case where we do know that the injection will work immediately.

Also, it's not that someone else might need it. We know our application
will need to fully use it soon. It's not "may", but "will". :)


Thanks,
Razvan Cojocaru


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


 


Rackspace

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