From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbBg9-0001GC-Kw for qemu-devel@nongnu.org; Thu, 26 Mar 2015 13:34:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbBg4-0001tS-BP for qemu-devel@nongnu.org; Thu, 26 Mar 2015 13:34:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36892) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbBg4-0001sv-5m for qemu-devel@nongnu.org; Thu, 26 Mar 2015 13:34:44 -0400 Date: Thu, 26 Mar 2015 18:34:39 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Message-ID: <20150326173438.GB13271@potion.brq.redhat.com> References: <20150325205439.GA21667@morn.localdomain> <20150325230259.GA29924@morn.localdomain> <20150326000502.GA1217@morn.localdomain> <20150326155807.GA13271@potion.brq.redhat.com> <20150326163657.GA16305@morn.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150326163657.GA16305@morn.localdomain> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] E5-2620v2 - emulation stop error List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: Andrey Korolyov , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "Dr. David Alan Gilbert" , Bandan Das , Gerd Hoffmann , Paolo Bonzini 2015-03-26 12:36-0400, Kevin O'Connor: > On Thu, Mar 26, 2015 at 04:58:07PM +0100, Radim Kr=C4=8Dm=C3=A1=C5=99 w= rote: > > Notice the 0xef. My best hypothesis so far is that we fail at resett= ing > > devices, and 0xef is LOCAL_TIMER_VECTOR from Linux before we rebooted= . > > (The bug happens at the first place that enables interrupts.) >=20 > FYI, the "int $0x19" isn't the first place SeaBIOS will enable > interrupts. Each screen print (every character in the seabios banner > and uuid string) will call the vga bios (int $0x10) with irqs enabled > (see output.c:screenc). Most useful, thank you. So interrupt can't be "forgotten" there on reboot ... it's possible that a pending timer injects it later. (I'd like to grasp the reason behind 0xef first.) > Also, SeaBIOS loads a default vector (f000:ff53) at 0xef which does a > simple "iretw". The #GP error code could help a bit here. > Things that are unusual about the "int $0x19" call: > - it is likely the first place that the cpu is transitioned into > 16bit real mode as opposed to "big real" mode. (That is, the > first place interrupts are enabled with the segment limits set to > 0xffff.) > - it's right after the fw/shadow.c:make_bios_readonly() call, which > attempts to configures the memory at 0xf0000-0x100000 as > read-only. That code also issues a wbinvd() call. (I'll wait for the trace before doing more wild guesses ...)