[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

From: Sebastian Herbszt
Subject: Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios
Date: Wed, 25 Nov 2009 23:04:20 +0100

Gleb Natapov wrote:
On Wed, Nov 25, 2009 at 06:09:51AM +0000, Jamie Lokier wrote:
Gleb Natapov wrote:
> > But QEMU is used to run old OSes too.
> > > That's OK. I don't expect BIOS to be reloaded if OS restart by jumping
> to BIOS reset code.

That's good then.

What about DOS and DOS-extender programs which do a soft reset by
triple-faulting the CPU (see Sebastian's notes on i440FX behaviour),
and asking the keyboard controller?

Both of those methods are used by DOS and DOS-extender programs to
switch from protected mode to real mode.  Keyboard controller was used
originally, but then someone figured out that triple fault can be used
(on most PCs) and is faster.

The switch to real mode is done by writing somewhere the BIOS checks,
so the BIOS just branches back to the application.

If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored
in memory address 0x467.

I think that may imply it has to be a "soft reset" as described by
Sebastian in the i440FX description, and I would think the BIOS must
not be reloaded.
Reading ich9 spec I see that on this chipset it is possible to configure
what kind of reset triple fault generates. Make it not very reliable. Was
this triple fault trick only needed on 286 anyway?

It seems to be INIT# vs. PLTRST# (Platform Reset). On the latter all devices
are reset. Table 5-40 is pretty descriptive and there seem to be way too many
ways to trigger a reset. I think PLTRST# is used when a reset is triggered by
the ACPI method. Fortunatelly we don't have to implement this (yet) since
it's not available on  the 440fx.

Using triple fault to reset is used on 286+.

But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
controller method is used and the word asking for a branch back to the
application has not been set.  Because that's how a modern OS (if not
using ACPI) asks for a system reset.

Do you think the above is (a) correct, and (b) what's implemented?

Do different things during reset depending on CMOS values doesn't sound
right to me. I don't know what is implemented right now. I thought that
we reload BIOS on reset.

Currently the BIOS seems to be only loaded once and not reloaded during the life
time of a VM.
I don't think there is a notion of BIOS reload on real hardware. CPU access to 
it is
either directed to the rom (power-up configuration, all those fancy reset 
or to ram.
How is shadowing currently implemented in qemu? Is the only BIOS copy 
or is the rom copy separate from the ram copy?

- Sebastian

reply via email to

[Prev in Thread] Current Thread [Next in Thread]