From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH RFC V9 4/5] xen, libxc: Request page fault injection via libxc Date: Mon, 01 Sep 2014 10:08:56 +0100 Message-ID: <540453C8020000780002F59C@mail.emea.novell.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> <540421E1.9020505@bitdefender.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XONbi-0000EQ-Tm for xen-devel@lists.xenproject.org; Mon, 01 Sep 2014 09:09:03 +0000 In-Reply-To: <540421E1.9020505@bitdefender.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Razvan Cojocaru Cc: kevin.tian@intel.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, eddie.dong@intel.com, tim@xen.org, jun.nakajima@intel.com, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com List-Id: xen-devel@lists.xenproject.org >>> On 01.09.14 at 09:36, wrote: > 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? Maybe, but only after you explained why the existing interface can neither be used nor suitably extended. Jan