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: Mon, 30 Nov 2009 21:34:58 +0100

Gleb Natapov wrote:
On Fri, Nov 27, 2009 at 09:42:19PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
>On Thu, Nov 26, 2009 at 09:55:28PM +0100, Sebastian Herbszt wrote:
>>Gleb Natapov wrote:
>>>On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote:
>>>>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+.
>>>>
>>>Triple fault use as a reset is widely used today. Use of triple fault to
>>>switch from protected mode to real mode was specific for 286.
>>
>>Whether triple fault is used just for a reset or to switch from protected 
mode to real
>>mode is irrelevant, because from the hardware point of view this is exactly 
the same
>>reset. And old applications can still use this method on new CPUs.
>>
>If triple fault is used just for a reset we can do hard reset like we do
>now. It may violate HW spec but it works.

Bad things might happen tho, because some of the hardware state is reset even 
if it should
not be. If some OS does program the PIIX3 PIRQx route control registers and 
then uses
triple fault to return from protected mode and qemu does reset those registers 
back to
default values, the OS might not like it when the BIOS resumes it.

We already concluded that "return to PM by triple fault" is not something
we want to support. It was needed only on 286 and QEMU doesn't even
support 286 cpu emulation.

I don't think you can conclude this because it's not an optional feature. 
Whether qemu
emulates a 286 cpu is irrelevant in this case because the hardware qemu 
emulates has
to be backward compatible.

>>>>>>
>>>>>>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 
conditions)
>>>>or to ram.
>>>Reloading BIOS in QEMU is needed for a reason not present on real HW. Think
>>>about migration from old QEMU to new QEMU. Suppose old BIOS can't
>>>properly initialize new QEMU. Then next reboot after migration will fail
>>>since old BIOS will be used.
>>
>>Do you mean live migration between different QEMU versions? That doesn't 
sound safe,
>>especially if the hardware changes on reboot. Does the competition support 
this?
>>
>Of course. The ability to upgrade cluster transparently is a major
>feature. So migration from older version to newer one is must to have.

I am wondering how this works on VMware. A VM has a virtualHW.version assigned, 
so the
hardware doesn't automagically change on software upgrades. You have to power 
off the VM
and request an upgrade for it to change. They also likely have a fairly stable 
BIOS version.
If a VM is created on ESX 3.5 with virtualHW.version 4 and live migrated to ESX 
4.0, which also
supports virtualHW.version 7, i would assume it still has the same hardware on 
a hard reset and even
if you shutdown and restart it, since no hardware upgrade was requested by the 
user. If the hardware
has been upgraded it can't be migrated back to the ESX 3.5 host. The BIOS might 
be special tho. It does
likely support both hardware versions. If the VM got migrated, the old BIOS 
should be run and reloaded
as long as the VM has not been destroyed / stopped. This should happen even if 
the VM has been hard reset.
Now if the VM is shutdown and recreated on the new host it might be ok to load 
the new BIOS even if the
hardware version was not upgraded. But it is more (?) reasonable to keep 
loading the old BIOS until the
hardware is upgraded and leave the choice to the user.

You are talking about major HW upgrades and I am not talking about that
at all. You can't migrate from i440FX to ich9 obviously. I am talking
about bug fixes in existing HW. For instance currently LINT0 is
configured to virtual wire mode by KVM itself, but it should be done by
a BIOS. Suppose new version of KVM fixes this bug, code that did this is
removed from KVM module and LINT0 configuration is added to a BIOS. Now
you migrate old guest to the new QEMU/KVM and do reboot. If old BIOS
will be executed it will not put LINT0 to virtual wire mode and new KVM
will not do that too. OS boot will fail as a result. That is only one
example from real life and I have more.

This is unfortunate. Updating the BIOS of a running VM might not be the best 
idea; tho i don't have a better one.
An unfriendly solution would be to disallow live migration between broken and 
fixed versions.

- Sebastian





reply via email to

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