[SeaBIOS] varlow/extrastack vs code

[Paolo Bonzini]

On 15/02/2017 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.  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.

My memories are fuzzy, but I remember discussing whether the PAM
registers should be preserved or not by S3, and I think the answer was
that on real hardware they are preserved by S3.

Now, S3 is mostly the same as a reset from the firmware's point of view.
 The conclusion then would be that a reset should _not_ be touching the
PAM registers.

Paolo