On Wed, Nov 25, 2009 at 05:53:49PM -0500, Kevin O'Connor wrote:
> On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote:
> >> 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 conditions) or to ram.
>
> I see a "BIOS reload" as equivalent to directing access to rom.
>
> > How is shadowing currently implemented in qemu? Is the only BIOS
> > copy overwritten or is the rom copy separate from the ram copy?
>
> My understanding is that both the ram and rom are kept. (Though, on a
> "BIOS reload" I don't know if the ram is preserved.)
>
>
> To summarize the discussion so far, there seems to be a potential
> issue with reset:
>
> * If qemu doesn't reload the bios (a soft-reset) then there is a
> potential issue with the bios and option roms not running properly
> after a system reset invoked by Linux or other modern OSs.
>
> * If qemu does reload the bios (a hard-reset) then there is a good
> chance that old DOS programs will break when they invoke a reset in
> an attempt to switch from protected mode to real mode.
>
> Is that correct?
>
Reloading of a BIOS will not prevent old DOS program from working.
It will slow switch to real mode, but otherwise I see no harm. What may
prevent them from working is the fact that too much devices are reset on
triple fault, but this has nothing to do with reloading of a BIOS.
--
Gleb.
