qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 4/3] wakeup: only reset the CPU


From: Kevin O'Connor
Subject: Re: [Qemu-devel] [PATCH 4/3] wakeup: only reset the CPU
Date: Tue, 5 Mar 2013 20:45:15 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]