From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tamas K Lengyel Subject: Re: [PATCH 00/11] Alternate p2m: support multiple copies of host p2m Date: Thu, 5 Mar 2015 00:06:23 +0100 Message-ID: References: <54B579CD.60804@intel.com> <54B583FC.4060800@citrix.com> <54B58E90.20309@intel.com> <54B6151402000078000C580B@mail.emea.novell.com> <54B65C920200007800054BAD@mail.emea.novell.com> <54B6A8D9.904@intel.com> <54B78555020000780005526B@mail.emea.novell.com> <54B7F8A7.2010407@intel.com> <20150115174517.GL57240@deinos.phlegethon.org> <54B80A9B.7050000@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54B80A9B.7050000@intel.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: Ed White Cc: Keir Fraser , Ian Campbell , Andrew Cooper , Ian Jackson , Tim Deegan , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org >>>>> Right. The key observation is that at any single point in time, a given >>>>> hardware thread can be fetching an instruction or reading data, but not >>>>> both. >>>> >>>> Fine, as long as an instruction reading itself isn't going to lead to >>>> a live lock. >>>> >>> >>> That's not how the hardware works. By the time you figure out that the >>> instruction you are executing reads memory, the instruction itself has >>> been fetched and decoded. That won't happen again during this execution. >> >> Can you explain? If the instruction faults and is returned to, >> execution starts again, right? So for an instruction that reads itself: >> >> - the fetch succeeds; >> - the read fails, and we fault; >> - the hypervisor switches from mapping MFN 1 (--x) to MFN 2 (r--); >> - the hypervisor returns to the guest. >> >> Are you relying on the icache/trace cache/whatever to restart >> the instruction from a cached value rather than fault immediately? >> (Because the hypervisor didn't flush the TLB when it changed the mapping)? >> > > Nope. I just typed before drinking enough coffee. That whole answer was bogus. > > Of course, if an instruction reads itself you can get a live lock using > these techniques, but it's a software-induced live lock and software can > avoid it. One way is compare the address being read with the instruction > pointer, and if they are on the same page emulate instead of switching p2m's. > > Ed Hi Ed, we have been poking at this idea of achieving singlestepping through altp2m view-switching (which would be supported by the VMFUNC EPTP-switching) and the problem discussed above is not limited to instructions that perform data accesses on the same page where the instruction executing was fetched from. In order to achieve true single-stepping, the immediate next instruction should be causing an EPT violation. Let's assume we trap an instruction that only performs data accesses on pages other than the one the instruction was fetched from. Since the instruction fetch is repeated after a failed data access due to EPT violation, the page containing the instruction has to be at least --x and the pages that will be touched by it rw- (or the proper combination or r-- and rw-) simultaneously in order to avoid getting into a live-lock. This results in all subsequent instruction fetches to succeed from the original page. Furthermore, as long as all such subsequent instructions keep accessing only the pages touched by the first instruction, we could end up missing a good chunk of code execution. Is there something we are missing here or is this a known limitation to the EPT-based singlestepping mechanism? Or is there something in the way VMFUNC is implemented that will avoid this limitation? Thanks, Tamas