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

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

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?


Thanks,
Razvan Cojocaru

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