[SeaBIOS] varlow/extrastack vs code
Kevin O'Connor
kevin at koconnor.net
Tue Feb 14 18:16:32 CET 2017
On Tue, Feb 14, 2017 at 05:36:34PM +0100, Laszlo Ersek wrote:
> On 02/14/17 17:22, Kevin O'Connor wrote:
> > On Tue, Feb 14, 2017 at 02:50:23PM +0000, Dr. David Alan Gilbert wrote:
> >> I've been sporadically carrying on debugging this and I
> >> think I have a bit more understanding, but not quite all the way.
> >>
> >> I'm pretty sure we are trying to run code that's been over written
> >> by variable data - which I believe to be TimerLast, and I'm also
> >> fairly sure the problem is not a delayed reset from multiple reboot signals.
> >>
> >> Some detail:
> >> a) I added some debug to qemu to print what triggered the reboot by
> >> always passing qemu_system_reset_request a string; the kernel
> >> is always rebooting via KBD_CCMD_RESET, I see that enter the BIOS
> >> and then see SeaBIOS then does KBD_CCMD_RESET again - which I think
> >> is the one coming from handle_resume32.
> >> But then I noticed that every so often we got a reboot from a KVM_SHUTDOWN
> >> which is apparently a triple-fault or the like.
> >>
> >> b) With a KVM trace I got the addresses the fault was happening at,
> >> and it was always an address in the copy fo the bios around bffbcf..
> >> although the actual failure jumped about a bit, taking the:
> >> Relocating init from 0x000e4810 to 0xbffb2050 (size 57120)
> >> I worked the fault address back to 'ef799' and from the objdump
> >> found that was an address in maininit but also corresponded to
> >> TimerLast:
> >
> > I can confirm there is a defect with TimerLast and reboot handling.
> > I'm not sure what the best fix is - suggestions welcome.
> >
> > The root of the problem is that QEMU does not reset the f-segment on a
> > reboot signal
>
> Are you sure this applies to recent QEMU too, not just ancient QEMU?
>
> > and so SeaBIOS must manually reset that memory.
>
> Do you mean a workaround for the (historically lacking) emulation of the
> PAM chipset registers? PAM emulation has been correct for quite a while
> now in QEMU, as far as I can tell.
My understanding was that a write to the PCI reboot register (0x0cf9)
would cause a hard reboot - which would reset the PAM registers to
their default (a RO view of the pristine bios at 0xf0000). I just did
some tests with qemu v2.8 and it does not appear to do that.
Also, the PAM registers on real hardware support a mode where reads to
0xf0000 return the pristine copy of the bios while writes update
memory. I didn't think there was any interest in implementing that on
QEMU (nor do I think it would be particularly helpful to have).
-Kevin
More information about the SeaBIOS
mailing list