From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L5Iib-0000gi-Uz for qemu-devel@nongnu.org; Wed, 26 Nov 2008 06:38:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L5Iia-0000gD-CT for qemu-devel@nongnu.org; Wed, 26 Nov 2008 06:38:05 -0500 Received: from [199.232.76.173] (port=50669 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L5Iia-0000g2-4I for qemu-devel@nongnu.org; Wed, 26 Nov 2008 06:38:04 -0500 Received: from mx20.gnu.org ([199.232.41.8]:44796) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L5IiZ-0000Bq-TK for qemu-devel@nongnu.org; Wed, 26 Nov 2008 06:38:03 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L5IiX-0008LK-SR for qemu-devel@nongnu.org; Wed, 26 Nov 2008 06:38:02 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Modeling x86 early initialization accurately Date: Wed, 26 Nov 2008 11:37:55 +0000 References: <492C80BF.4010103@gmx.net> In-Reply-To: <492C80BF.4010103@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811261137.56040.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Carl-Daniel Hailfinger > - Start up with all RAM being readonly. Writes should be discarded, > reads will usually return 0xff or be undefined. The "undefined" variant > would allow the code to allocate RAM once and just switch write access > on/off. Does anything actually rely on this behavior? I can see the need to the other bits, but it seems kinda strange that anything would rely on RAM being readonly. This seems more like a coreboot bug than anything else. Paul