From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [PATCH 1/3] libxc/xc_domain_resume: Update comment.
Date: Tue, 26 Jan 2016 16:52:06 +0000
Message-ID: <22183.42038.212120.387010@mariner.uk.xensource.com>
References: <1453756017-8747-1-git-send-email-konrad.wilk@oracle.com>
	<1453756017-8747-2-git-send-email-konrad.wilk@oracle.com>
	<1453825194.25257.31.camel@citrix.com>
	<22183.40252.314004.359086@mariner.uk.xensource.com>
	<1453826168.25257.40.camel@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=826bacb61=Ian.Jackson@citrix.com>)
	id 1aO6qg-0006WI-KR
	for xen-devel@lists.xenproject.org; Tue, 26 Jan 2016 16:52:10 +0000
In-Reply-To: <1453826168.25257.40.camel@citrix.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: Ian Campbell <ian.campbell@citrix.com>
Cc: xen-devel@lists.xenproject.org, wei.liu2@citrix.com
List-Id: xen-devel@lists.xenproject.org

Ian Campbell writes ("Re: [PATCH 1/3] libxc/xc_domain_resume: Update commen=
t."):
> On Tue, 2016-01-26 at 16:22 +0000, Ian Jackson wrote:
> > I'm not sure that `will return 1' is correct.=A0=A0IIRC there is some
> > ... unpleasantness here, with something effectively corrupting the
> > guest state in a way that the guest is supposed to expect and
> > cooperate with.
> =

> The tools arrange for the hypercall to return 1, which the guest is indeed
> expected to expect and cooperate, as with any PV interface call it makes.
> =

> They do this by intimate knowledge of the hypercall ABI (i.e. which
> register is the return value) and one could certainly argue it ought to be
> arranged in a less horrific way, but I think to characterise it as
> "corrupting" is probably going to far.

Ian C had a conversation about this in person.  We think (ie, I am now
convinced) that provided that this xc resume call is only made when
the guest is suspended, that the worst outcome will indeed be that the
guest experiences the hypercall returning 1, and then finding itself
in a state it's not expecting.  The guest will hopefully crash due
to the unexpected return value but is in any case likely to implode
soon due to event channel misconfiguration etc.

Only if the `resume' is attempted with the guest running, would the
guest's %eax actually be `corrupted' in this sense.

Ian.