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

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 09/01/2014 12:08 PM, Jan Beulich wrote:
>>>> On 01.09.14 at 09:36, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> On 08/29/2014 12:27 PM, Jan Beulich wrote:
>>>>>> On 29.08.14 at 09:44, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>> I do understand the preference for a VCPU-based mechanism from a
>>>> concurrency point of view, but that would simply potentially fail for
>>>> us, hence defeating the purpose of the patch. I'm also not sure how that
>>>> would be useful in the general case either, since the same problem that
>>>> applies to us would seem to apply to the general case as well.
>>>
>>> Yeah, the whole thing probably needs a bit more thinking so that the
>>> interface doesn't end up being a BitDefender-special. Indeed together
>>> with the address space qualification, the interface might not be very
>>> useful when made vCPU-bound. And taking it a little further into the
>>> "generic" direction, allowing this to only inject #PF doesn't make a
>>> very nice interface either. Plus we already have HVMOP_inject_trap,
>>> i.e. your first line of thinking (and eventual explaining as the
>>> motivation for a patch) should be why that can't be used.
>>
>> I'd say that it's memory-introspection specific rather than 3rd-party
>> vendor specific. Without this this patch, memory-introspection support
>> in general is impacted / less flexible, since there's no other way to
>> bring swapped out pages back in.
>>
>> For all the reasons you've explained (at least as far as I understand
>> it) there's not much room to go more generic - so maybe just renaming
>> the libxc wrapper to something more specific (
>> xc_domain_request_usermode_pagefault?) is the solution here?
> 
> Maybe, but only after you explained why the existing interface can
> neither be used nor suitably extended.

As far as I understand the HVMOP_inject_trap interface, it is simply (in
this case) a way to trigger the equivalent of hvm_inject_page_fault()
from userspace (via libxc).

We need two additional checks:

1. That CR3 matches, because the way the application works, we need to
inject a page fault related to the address space of whatever process is
interesting at the time, and

2. That we're in usermode (the CPL check), because we know that it's
safe to inject a page fault when we're in user mode, but it's not always
safe to do so in kernel mode.

The current interface seems to be a low-level, basic wrapper around
hvm_inject_trap().

What we're trying to do is ask for a page fault when we're both A) in
usermode, and B) when a target process matches - and are only interested
in page faults, no other trap vector.

Technically, the checks could, probably, be moved into (and new
parameters added to) hvm_inject_trap() & friends, but it seems unlikely
that users other than memory introspection applications would be
interested in them, while they would possibly add to the complexity of
the interface. The rest of the clients would have to carry dummy
parameters around to use it.


Thanks,
Razvan Cojocaru

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