qemu-devel
[Top][All Lists]
Advanced

[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: Thu, 26 Nov 2009 23:35:52 +0100

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

The BIOS is mapped read only in hw/pc.c
   bios_offset = qemu_ram_alloc(bios_size)
...
   cpu_register_physical_memory(0x100000 - isa_bios_size,
                                isa_bios_size,
                                (bios_offset + bios_size - isa_bios_size) | 
IO_MEM_ROM);

Then it is remapped by update_pam() in hw/piix_pci.c

       cpu_register_physical_memory(start, end - start,
                                    start);

Since the memory is only allocated once i assume when the content gets 
overwritten
because of shadowing the original data is gone.

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 a system reset (hard, power cycle) is requested and the hardware is reset to
the default power up state and it does require an option rom to initialize, but 
the
option rom is not reloaded and was shrunk and now only contains the runtime 
part,
there will likely be a problem.

Maybe the expansion rom bar can be used for pci devices like on real hardware. 
The bios
will check it and load the rom itself instead of relying on qemu to do the job.

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

If a soft reset is requested with the goal of a transition from protected to 
real mode and the bios
is reloaded, it should not do any harm because the internal device states are 
kept and the cmos
still has the correct shutdown status code for the transition. Bochs bios 
doesn't rely on shadowing
so none of its internal state is lost either, but the created tables (smbios, 
mp table, etc.) will be gone.

- Sebastian





reply via email to

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