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