On Fr, 2013-12-20 at 00:40 +0200, Michael S. Tsirkin wrote:
On Thu, Dec 19, 2013 at 11:32:03PM +0100, Laszlo Ersek wrote:
On 12/19/13 23:16, Michael S. Tsirkin wrote:
I suspect we need to init more devices, but I need to look some more into this. Basically whatever OS does not restore, we have to.
I don't think that implication is necessarily true. Just because neither restores some device state currently doesn't imply the firmware should restore it. The OS is much better equipped to restore complex state;
If you look at my patch, there's nothing complex there.
You don't restore state, you re-initialize things. That is something different.
In case of the i440fx northbridge this probably is pretty much the same as the smbase + pmbase register don't change at runtime. That isn't true for other devices though.
The Platform Init spec 1.2.1 says in Vol5, 8.5.1.3.1 DXE and the S3 Resume Boot Path,
The ACPI specification only requires the BIOS to restore chipset and processor configuration. [...]
All of PIIX and Q35 is part if the chipset though.
I doubt this includes all piix/q35 onboard devices (ide/sata, usb, nic, ...).
The smbios/pmbase register bases are a special case as these registers are needed do handle suspend and resume correctly. I suspect this is the reason why they are kind-of hidden (i.e. not implemented as normal pci i/o bars) in the first place.
Also chipset-specific configuration goes into this category I expect. Basically all the stuff you can configure in the bios setup utility on physical hardware, i.e. which LPC devices (serial, parallel, ...) are enabled/disabled, whenever the storage controller operates in legacy (aka IDE) or native (AHCI) mode, ...
I think we should go go a minimum patch which specifically reinitializes the registers which actually need reinitialization.
I'm not sure which part of the ACPI spec they refer to, and of course this statement may not be overly accurate either, but it does seem to limit the firmware's responsibility.
Laszlo
Basically OSes are tested on real hardware. Whatever firmware for real boards restores, OS-es won't restore so we have to.
For USB host controllers I'm sure this is the job of the OS. At least the linux kernel handles it just fine. It'll figure whenever the uhci controller lost power, if not it resumes the controller, otherwise it does a full re-initialization and usb bus scan. On qemu the later is done as we do a full device reset on s3 resume.
xhci controllers have facilities to save/restore internal state to/from ram, so the OS doesn't need to do a full bus rescan on resume even in case the xhci controller is fully powered off.
cheers, Gerd