From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH RFC V9 4/5] xen, libxc: Request page fault injection via libxc Date: Wed, 10 Sep 2014 10:34:43 +0100 Message-ID: <54101B33.7040205@citrix.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> <541011F1.70106@bitdefender.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 1XReIc-0006rW-9v for xen-devel@lists.xenproject.org; Wed, 10 Sep 2014 09:34:50 +0000 In-Reply-To: <541011F1.70106@bitdefender.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: Razvan Cojocaru , 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 10/09/14 09:55, Razvan Cojocaru wrote: > 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. Right. I can see your concern, but designing an interface like this for some hopeful future can be problematic, especially given only a vague idea of how it would be used in practice. With the Xen hypercall API/ABI, it is always possible to add something in the future, and a concrete example of how it is suppose to work does greatly help with justifying its design and implementation. In this case, I feel that extending mem_event responses is a very natural thing to do. It very closely ties the pagefault to the action which resulted in the decision for a pagefault, rather than an apparently asynchronous pagefault request via another mechanism which userspace has to use when it knows that the vcpu is blocked on a mem_event. Furthermore, having a general "please inject a fault which looks like this" mechanism allows the mem_event userspace agent algorithm to choose to inject other faults for different circumstances. ~Andrew