All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Kevin O'Connor <kevin@koconnor.net>
Cc: bochs-developers@lists.sourceforge.net, qemu-devel@nongnu.org,
	Sebastian Herbszt <herbszt@gmx.de>
Subject: [Qemu-devel] Re: [Bochs-developers] [PATCH v5 1/5] Add S3 state to DSDT.Handle resume event in the BIOS.
Date: Wed, 10 Dec 2008 12:22:36 +0200	[thread overview]
Message-ID: <20081210102236.GC5555@redhat.com> (raw)
In-Reply-To: <20081210000604.GA15974@morn.localdomain>

On Tue, Dec 09, 2008 at 07:06:04PM -0500, Kevin O'Connor wrote:
> On Tue, Dec 09, 2008 at 11:26:53PM +0100, Sebastian Herbszt wrote:
> > Gleb Natapov wrote:
> > > On Sat, Dec 06, 2008 at 09:57:38PM -0500, Kevin O'Connor wrote:
> > >> Also, wouldn't this corrupt memory used by the stack (the stack gets
> > >> set to 0xfffe, and s3_post has call insns in it)?
> > > Oh. I thought it was set to be at the top of the first page, but it has
> > > one extra 'f' :( We should change it to be 0xffe instead.
> > 
> > Can you please explain this memory corruption? Why would "this" (?) corrupt
> > memory used by the stack?
> 
> On an s3 resume, memory the OS may be using must not be changed by the
> bios.  When bochs bios detects an s3 resume, it jumps to s3_post with
> the stack pointer set to 0xfffe.  In s3_post, there are "call"
> instruction which will alter memory at 0xfffe (to store the return
> address).  This could break the resume, because the OS could be using
> that memory for something else.
> 
> Gleb is suggesting that we change that to 0xffe, because the OS can't
> be using memory at that address and expect s3 resume to work.  (The
> first 4KiB is reserved for BIOS use.)
> 
And the patch I've sent set sp to 0xffe only on S3 resume path where
stack usage is minimal.

--
			Gleb.

  reply	other threads:[~2008-12-10 10:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-27 11:02 [Qemu-devel] [PATCH v5 0/5] Support for S3 ACPI state (suspend to memory) in BIOS Gleb Natapov
2008-11-27 11:02 ` [Qemu-devel] [PATCH v5 1/5] Add S3 state to DSDT. Handle resume event in the BIOS Gleb Natapov
2008-12-07  2:57   ` [Qemu-devel] Re: [Bochs-developers] " Kevin O'Connor
2008-12-07  9:20     ` Gleb Natapov
2008-12-07 15:10       ` Kevin O'Connor
2008-12-07 16:31         ` Gleb Natapov
2008-12-09 22:26       ` [Qemu-devel] Re: [Bochs-developers] [PATCH v5 1/5] Add S3 state to DSDT.Handle " Sebastian Herbszt
2008-12-10  0:06         ` Kevin O'Connor
2008-12-10 10:22           ` Gleb Natapov [this message]
2008-12-09 13:38     ` [Qemu-devel] Re: [Bochs-developers] [PATCH v5 1/5] Add S3 state to DSDT. Handle " Gleb Natapov
2008-12-09 15:12       ` [Qemu-devel] " Stanislav
2008-12-14 22:02       ` [Qemu-devel] Re: [Bochs-developers] [PATCH v5 1/5] Add S3 state to DSDT.Handle " Sebastian Herbszt
2008-11-27 11:02 ` [Qemu-devel] [PATCH v5 2/5] Preserve memory content during SMM init Gleb Natapov
2008-11-27 11:02 ` [Qemu-devel] [PATCH v5 3/5] Execute rombios32 code from rom address 0xe0000 Gleb Natapov
2008-11-27 11:02 ` [Qemu-devel] [PATCH v5 4/5] Don't use unreserved memory in BIOS Gleb Natapov
2008-11-27 11:02 ` [Qemu-devel] [PATCH v5 5/5] Don't power down vga card on entering S3 state Gleb Natapov
2008-11-27 12:17 ` [Qemu-devel] [PATCH v5 0/5] Support for S3 ACPI state (suspend to memory) in BIOS Carl-Daniel Hailfinger
2008-11-27 12:35   ` Gleb Natapov
2008-11-27 18:59     ` [Bochs-developers] " Stanislav
2008-11-27 19:07       ` Carl-Daniel Hailfinger
2008-11-27 20:04         ` Stanislav
2008-11-27 21:04           ` Carl-Daniel Hailfinger
2008-11-29 19:42             ` Stanislav
2008-12-04 10:04               ` Carl-Daniel Hailfinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081210102236.GC5555@redhat.com \
    --to=gleb@redhat.com \
    --cc=bochs-developers@lists.sourceforge.net \
    --cc=herbszt@gmx.de \
    --cc=kevin@koconnor.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.