From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tim Deegan <tim@xen.org>
Subject: Re: [PATCH 00/11] Alternate p2m: support multiple
 copies of host p2m
Date: Thu, 15 Jan 2015 18:45:17 +0100
Message-ID: <20150115174517.GL57240@deinos.phlegethon.org>
References: <54B579CD.60804@intel.com> <54B583FC.4060800@citrix.com>
	<54B58E90.20309@intel.com>
	<54B6151402000078000C580B@mail.emea.novell.com>
	<CAErYnshkCQxHcdFXj-UDeDV9Z5Umwh3QYtDrFDuQU+U3WV1Ohw@mail.gmail.com>
	<54B65C920200007800054BAD@mail.emea.novell.com>
	<CAErYnsgCpzjZuDJT7vaZcbZjhTmEGS+E8d1_UF9Z0RcC4HPa_w@mail.gmail.com>
	<54B6A8D9.904@intel.com>
	<54B78555020000780005526B@mail.emea.novell.com>
	<54B7F8A7.2010407@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <54B7F8A7.2010407@intel.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ed White <edmund.h.white@intel.com>
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>, Tamas K Lengyel <tamas.lengyel@zentific.com>, Ian Jackson <ian.jackson@eu.citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
List-Id: xen-devel@lists.xenproject.org

At 09:28 -0800 on 15 Jan (1421310487), Ed White wrote:
> On 01/15/2015 12:16 AM, Jan Beulich wrote:
> >>>> On 14.01.15 at 18:35, <edmund.h.white@intel.com> wrote:
> >> On 01/14/2015 03:28 AM, Tamas K Lengyel wrote:
> >>> At the mem_access trap point you can swap in an altp2m where the
> >>> gfn->mfn mapping is the one where the breakpoints are hidden,
> >>> singlestep, then swap the original p2m back. While this approach still
> >>> has some overhead because of the use of singlestepping, it is going to
> >>> be faster then what you currently have to do, which is removing all
> >>> breakpoints, singlestep, then put breakpoints back. Now it would just
> >>> be a matter of swapping a single pointer.
> >>
> >> 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)?

Cheers,

Tim.