On Tue, Mar 05, 2013 at 04:59:51PM +0000, David Woodhouse wrote: > On Tue, 2013-03-05 at 17:03 +0100, Paolo Bonzini wrote: > > Resuming from suspend-to-RAM should not reset all devices. Only the > > CPU should get a reset signal. > > Hm... on reflection, I don't actually know if this is true. > > Perhaps we *should* reset all devices. After all, in a real machine > they'll all have been turned off and the RAM will have been in > self-refresh. Surely they have to be reset? > > So maybe we should *let* the i440FX PAM registers get reset to point to > ROM. And fix the firmware to *cope* with that, check to see if the > shadow RAM already holds an image of a started-up firmware with the > correct checksum, and jump back to it. > > That is: perhaps it's a *SeaBIOS* bug that suspend/resume doesn't work > if the PAM configuration is reset?
On a real machine the firmware would query the available memory and its settings via the smbus and then program the memory controller. Programming the memory controller without accessing any memory is a non-trivial task. QEMU doesn't emulate this low-level hardware - nor does it even fully emulate the PAM registers. So, I think the question isn't what does real-hardware do (there's no gain to be had in emulating all of this). Instead, I think the question is - what makes the most sense. Given that the objective is to restore the memory image and reset everything else, I think it would be best for QEMU's S3resume to completely restore the memory image - including the PAM settings. -Kevin
