From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L56hz-0001pn-4O for qemu-devel@nongnu.org; Tue, 25 Nov 2008 17:48:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L56hw-0001m9-Bm for qemu-devel@nongnu.org; Tue, 25 Nov 2008 17:48:37 -0500 Received: from [199.232.76.173] (port=32775 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L56hw-0001m0-2D for qemu-devel@nongnu.org; Tue, 25 Nov 2008 17:48:36 -0500 Received: from mail.gmx.net ([213.165.64.20]:48633) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1L56hv-0000tg-LN for qemu-devel@nongnu.org; Tue, 25 Nov 2008 17:48:36 -0500 Message-ID: <492C80BF.4010103@gmx.net> Date: Tue, 25 Nov 2008 23:48:31 +0100 From: Carl-Daniel Hailfinger MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Modeling x86 early initialization accurately 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 Hi, current svn HEAD of QEMU assumes all RAM is available directly at x86 CPU startup. The ability to lock processor caches to function as RAM (Cache-as-RAM) is unimplemented as well. While that does make it easier for the shipped BIOS to set up working RAM (i.e. it does nothing about that right now), that simplification reduces the ability to run alternative firmwares for x86 in QEMU. coreboot (a free x86 firmware/BIOS replacement) is unable to use standard x86 early initialization because the MSRs for cache control (MTRRs) are completely unimplemented and ignored. Modeling ACPI S3 (Suspend-to-RAM) suffers from similar issues. Things which need to be changed to model x86 better: - 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. - Support MTRRs. -- Mention MTRR support in CPUID. -- I sent a patch to dump unknown MSR accesses in general and MTRR reads/writes in particular. The subject was "[Qemu-devel] [PATCH] x86 MTRR access dumping". -- It is not really needed to completely implement L1/L2 caches, but the ability to lock the cache with the help of MTRRs should be available. Areas with active locked cache do not send writes down to the RAM which is still readonly. The cache locking is done on a per-page basis (or even larger granularity), so it should be easier than having to handle single cache lines. - Decide what to do for RAM initialization. Do we switch RAM into read-write mode by a simple QEMU-specific MSR write? Do we want to implement all memory initialization hardware instead? - Adapt the currently shipped BIOS to these tasks and/or switch to coreboot+SeaBIOS. I'm willing to do most of the work if I know that this won't be rejected outright. Regards, Carl-Daniel