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

["Sebastian Herbszt" <herbszt@gmx.de>]

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