From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH RFC V9 4/5] xen, libxc: Request page fault injection via libxc Date: Tue, 9 Sep 2014 22:14:35 +0200 Message-ID: <20140909201435.GB82414@deinos.phlegethon.org> References: <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> 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 1XRRoW-0001X5-JI for xen-devel@lists.xenproject.org; Tue, 09 Sep 2014 20:14:56 +0000 Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: "Tian, Kevin" , Ian Campbell , Razvan Cojocaru , Stefano Stabellini , Andrew Cooper , "Dong, Eddie" , Jan Beulich , Jun Nakajima , xen-devel , Ian Jackson List-Id: xen-devel@lists.xenproject.org At 17:57 +0100 on 09 Sep (1410281829), George Dunlap wrote: > On Tue, Sep 2, 2014 at 2:24 PM, Tim Deegan wrote: > > Hi, > > > > At 12:18 +0300 on 02 Sep (1409656686), Razvan Cojocaru wrote: > >> While we need to set the data per-domain and have whatever VCPU inject > >> the page fault - _but_only_if_ it's in usermode and its CR3 points to > >> something interesting. > > > > That's a strange and specific thing to ask the hypervisor to do for > > you. Given that you can already trap CR3 changes as mem-events can > > you trigger the fault injection in response to the contect switch? > > I guess that would probably catch it in kernel mode. :( > > I was wondering, rather than special-casing inject_trap, would it make > sense to be able for the memory controller to get notifications when > certain more complex conditions happen (e.g., "some vcpu is in user > mode with this CR3")? Then the controller could ask to be notified > when the event happens, and when it does, just call inject_fault. Yes, that sounds like a better place to put this kind of test. As part of the mem_event trigger framework it doesn't seem nearly so out of place (and it avoids many of the problems of clashes between different event injection paths). > That way, inject_fault isn't special-cased at all; and one could > imagine designing the "condition" such that any number of interesting > conditions could be trapped. > > Thoughts? > > 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? Yeah; I was thinking about page-protecting the process's stack as an approach to this. Breakpointing the return address might work too but would probably cause more false alarms -- you'd at least need to walk up past the libc/win32 wrappers to avoid trapping every thread. Ideally there'd be something vcpu-specific we could tinker with (e.g. arranging MSRs so that SYSRET will fault) once we see the right CR3 (assuming intercepting CR3 is cheap enough in this case). Tim.