From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1L5foB-0001Er-B9
	for qemu-devel@nongnu.org; Thu, 27 Nov 2008 07:17:23 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1L5fo8-0001EP-Jf
	for qemu-devel@nongnu.org; Thu, 27 Nov 2008 07:17:22 -0500
Received: from [199.232.76.173] (port=34482 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1L5fo8-0001EM-EY
	for qemu-devel@nongnu.org; Thu, 27 Nov 2008 07:17:20 -0500
Received: from mail.gmx.net ([213.165.64.20]:44316)
	by monty-python.gnu.org with smtp (Exim 4.60)
	(envelope-from <c-d.hailfinger.devel.2006@gmx.net>)
	id 1L5fo7-0004Yf-RE
	for qemu-devel@nongnu.org; Thu, 27 Nov 2008 07:17:20 -0500
Message-ID: <492E8FCC.2020203@gmx.net>
Date: Thu, 27 Nov 2008 13:17:16 +0100
From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH v5 0/5] Support for S3 ACPI state (suspend
	to	memory) in BIOS
References: <20081127110220.25353.83454.stgit@dhcp-1-237.tlv.redhat.com>
In-Reply-To: <20081127110220.25353.83454.stgit@dhcp-1-237.tlv.redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: bochs-developers@lists.sourceforge.net

Hi,

On 27.11.2008 12:02, Gleb Natapov wrote:
> This patch series adds S3 (suspend to RAM) ACPI state to BIOS. Most
> changes concern themselves with preventing BIOS from using memory
> locations available to a guest OS.
>   

I see the problem you're facing with the overwrite and it looks there
might be a cleaner solution: If you can lock the CPU cache so that
writes don't get passed through to RAM, you're free to use any area
(with a few contraints) for stack without having to worry about
clobbering memory contents there.

That method is called Cache-as-RAM and I'm currently trying to implement
it in Qemu. I haven't looked into Bochs yet, but it should be doable
there as well.

coreboot (a free x86 firmware/BIOS replacement) is using Cache-as-RAM
and I believe quite a few commercial BIOSes use that technique as well.

Regards,
Carl-Daniel