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


Xen-devel mailing list



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