Re: [Xen-devel] Xen-4.3 - curious crash

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 29/01/14 09:42, Jan Beulich wrote:
>>>> On 29.01.14 at 10:25, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> On Wed, 2014-01-29 at 09:01 +0000, Jan Beulich wrote:
>>>>>> On 29.01.14 at 09:51, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>>>> On Wed, 2014-01-29 at 08:43 +0000, Jan Beulich wrote:
>>>>> An interrupt not properly restoring EFLAGS.IF (or actually one not
>>>>> properly restoring all of EFLAGS) would be very odd. About as odd
>>>>> as a cosmic radiation induced bit flip resulting in some other
>>>>> misbehavior.
>>>> Isn't it also the affect of a missing spin_unlock(_irqrestore)? Or does
>>>> something else catch that first?
>>> A missing plain spin_unlock() wouldn't have any effect of IF. And
>>> a missing spin_unlock_irqrestore() would have an effect on IF in
>>> the interrupt handler, but with the return being through an IRET
>>> something would need to actively modify the flags on the stack
>>> that IRET uses in order to affect the interrupted code's EFLAGS.
>> Ah, I mistakenly thought that this issue was happening on that return
>> path (i.e. before the IRET).
> Right - the problem is that we're having two return paths to
> consider here: The outer one (wanting to return to the guest)
> explicitly used STI a few instructions before the crash. And it
> would need to be an inner one (hardware interrupt) that would
> have to fail to restore IF properly, and for that to happen the
> EFLAGS image used by that exit path's IRET would need to get
> corrupted.
>
> Jan
>

This issue has been seen exactly once, on an otherwise perfectly stable
server, which is running stably since.  I certainly have no evidence to
rule out cosmic radiation.

I suppose all that can be done at this point is to wait and see whether
it reoccurs.

~Andrew

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