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: Wed, 10 Sep 2014 11:55:13 +0300 Message-ID: <541011F1.70106@bitdefender.com> References: <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> <540453C8020000780002F59C@mail.emea.novell.com> <54045E7C.50604@bitdefender.com> <54047D1D020000780002F73A@mail.emea.novell.com> <54058B4E.9060001@bitdefender.com> <20140902132434.GA24202@deinos.phlegethon.org> <540F3B46.1030602@bitdefender.com> <54100722.1090604@bitdefender.com> <54101047.4060901@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XRdgK-0003jM-LQ for xen-devel@lists.xenproject.org; Wed, 10 Sep 2014 08:55:16 +0000 Received: from smtp02.buh.bitdefender.net (smtp.bitdefender.biz [10.17.80.76]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id C9D0D80086 for ; Wed, 10 Sep 2014 11:55:11 +0300 (EEST) In-Reply-To: <54101047.4060901@citrix.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: Andrew Cooper , Tamas K Lengyel Cc: "Tian, Kevin" , Ian Campbell , Stefano Stabellini , Jun Nakajima , "Dong, Eddie" , George Dunlap , Tim Deegan , Jan Beulich , xen-devel , Ian Jackson List-Id: xen-devel@lists.xenproject.org On 09/10/2014 11:48 AM, Andrew Cooper wrote: > On 10/09/2014 09:09, Razvan Cojocaru wrote: >> On 09/09/2014 09:38 PM, Tamas K Lengyel wrote: >>> > But ultimately, as Tim said, you're basically just *hoping* that it >>> > won't take too long to happen to be at the hypervisor when the proper >>> > condition happens. If the process in question isn't getting many >>> > interrupts, or is spending the vast majority of its time in the >>> > kernel, you may end up waiting an unbounded amount of time to be able >>> > to "catch" it in user mode. It seems like it would be better to find >>> > a reliable way to trap on the return into user mode, in which case you >>> > wouldn't need to have a special "wait for this complicated event to >>> > happen" call at all, would you? >>> >>> Indeed, but it is assumed that the trap injection request is being made >>> by the caller in the proper context (when it knows that the condition >>> will be true sooner rather than later). >>> >>> >>> How is it known that the condition will be true soon? Some more >>> information on what you consider 'proper context' would be valuable. >> It's actually pretty simple for us: the application always requests an >> injection when the guest is already in the address space of the >> interesting application, and in user mode. > > Does this mean that you always request a pagefault as a direct result of > a mem_event, when the vcpu is in blocked the correct context? Yes, exactly. > If so, how about extending the mem_event response mechanism with > trap/fault information? For this particular case, that is indeed a very good suggestion - however, things may change. From what I understand, it is likely that in the future we (or somebody else doing memory introspection) will need to request a page fault injection in other cases. The risks described above will of course exist in that case, but they are acceptable. Thanks, Razvan Cojocaru