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