[SeaBIOS] varlow/extrastack vs code

[Laszlo Ersek]

On 02/15/17 16:52, Kevin O'Connor wrote:
> On Wed, Feb 15, 2017 at 11:01:03AM +0100, Laszlo Ersek wrote:
>> On 02/14/17 20:14, Kevin O'Connor wrote:
>>> On Tue, Feb 14, 2017 at 07:52:01PM +0100, Laszlo Ersek wrote:
>>>> If item (1) is fixed in QEMU, then the above "root cause" goes away, and
>>>> the workaround in SeaBIOS can be conditionalized. Am I wrong?
>>>
>>> I'm not sure.  If I recall correctly, there are different resets on
>>> the x86 - some only reset the cpu and some do a "full machine reset".
>>> SeaBIOS attempts a variety of different reset mechanisms to reboot and
>>> I'm not sure which are supposed to do the full reset.  If seabios does
>>> a "reset cpu" mechanism before a "reset machine" mechanism, then qemu
>>> resetting the pam may not help.
>>
>> To my knowledge, QEMU implements only one kind of system reset, with
>> qemu_system_reset_request(). It is supposed to
>> - reset all VCPUs (it puts all APs back into "wait for
>>   INIT-SIPI-SIPI"),
>> - reset all chipset registers,
>> - reset all devices,
>> - not touch guest RAM.
> 
> Thanks Laszlo - I appreciate your very detailed response.
> 
> Way back in the day, the 286 had no way to return to real mode from
> protected mode.

That's... unexpected :)

> So, the BIOS had this funky method of detecting fake
> reboots to use as a mode switch.  If there is only one kind of QEMU
> reset then I think resetting the pam register in it would break this
> type of resume in SeaBIOS.  :-/
>
> So, I'm not sure what the right approach is wrt the PAM registers.

Can we perhaps provide a hint via fw_cfg, to convince SeaBIOS that
reboots are not fake (hence no need to detect them)?

If not (or if it would be ugly -- it would have to pass QEMU review
too!), I'm fine going with a SeaBIOS-side fix, of course. (Today's been
crazy again so I don't immediately recall the details of the suggested
SeaBIOS-side fix, but I seem to remember that there was one.)

Thanks!
Laszlo