From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH RFC V9 4/5] xen, libxc: Request page fault injection via libxc Date: Mon, 01 Sep 2014 10:36:01 +0300 Message-ID: <540421E1.9020505@bitdefender.com> References: <1409226482-12657-1-git-send-email-rcojocaru@bitdefender.com> <1409226482-12657-4-git-send-email-rcojocaru@bitdefender.com> <53FF36A1020000780002EAED@mail.emea.novell.com> <53FF1BD8.5010401@bitdefender.com> <53FF38A6020000780002EB2B@mail.emea.novell.com> <54002F43.4070802@bitdefender.com> <5400638A020000780002EFD6@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XOM9F-0007OA-JS for xen-devel@lists.xenproject.org; Mon, 01 Sep 2014 07:35:33 +0000 In-Reply-To: <5400638A020000780002EFD6@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: kevin.tian@intel.com, eddie.dong@intel.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, tim@xen.org, jun.nakajima@intel.com, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org On 08/29/2014 12:27 PM, Jan Beulich wrote: >>>> On 29.08.14 at 09:44, 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