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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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