From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ed White <edmund.h.white@intel.com>
Subject: Re: [PATCH 00/11] Alternate p2m: support multiple
 copies of host p2m
Date: Fri, 16 Jan 2015 08:54:45 -0800
Message-ID: <54B94255.8010902@intel.com>
References: <1420838801-11704-1-git-send-email-edmund.h.white@intel.com>
	<54B56B79.3010109@citrix.com> <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>
	<54B8CD440200007800055AA1@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <54B8CD440200007800055AA1@mail.emea.novell.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: Jan Beulich <JBeulich@suse.com>, Tamas K Lengyel <tamas.lengyel@zentific.com>
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 01/15/2015 11:35 PM, Jan Beulich wrote:
>>>> On 15.01.15 at 18:28, <edmund.h.white@intel.com> wrote:
>> On 01/15/2015 12:16 AM, Jan Beulich wrote:
>>>>>> On 14.01.15 at 18:35, <edmund.h.white@intel.com> wrote:
>>>> 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.
>>
>> That's true for every CPU I've ever seen, not just Intel ones.
> 
> Certainly not if either the fetch or the data read faults/vmexits.

Sorry about that. As I explained, I rushed off a response before
actually engaging my brain.

Ed