Re: [Xen-devel] [PATCH 1/3] libxc/xc_domain_resume: Update comment.

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Jan 26, 2016 at 04:52:06PM +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 1/3] libxc/xc_domain_resume: Update 
> comment."):
> > On Tue, 2016-01-26 at 16:22 +0000, Ian Jackson wrote:
> > > I'm not sure that `will return 1' is correct.  IIRC 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.

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

Right. That code doing the set_vcpu manipulations is quite .. ahhh
interesting!

I will update the comment to be more clear.
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel