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