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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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


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