From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L59m1-0006Ha-N6 for qemu-devel@nongnu.org; Tue, 25 Nov 2008 21:05:01 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L59m0-0006Ge-44 for qemu-devel@nongnu.org; Tue, 25 Nov 2008 21:05:00 -0500 Received: from [199.232.76.173] (port=57638 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L59lz-0006GW-RN for qemu-devel@nongnu.org; Tue, 25 Nov 2008 21:04:59 -0500 Received: from yw-out-1718.google.com ([74.125.46.156]:15605) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L59lz-00018c-9J for qemu-devel@nongnu.org; Tue, 25 Nov 2008 21:04:59 -0500 Received: by yw-out-1718.google.com with SMTP id 6so134109ywa.82 for ; Tue, 25 Nov 2008 18:04:58 -0800 (PST) Message-ID: <492CAEC8.4010306@codemonkey.ws> Date: Tue, 25 Nov 2008 20:04:56 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Modeling x86 early initialization accurately References: <492C80BF.4010103@gmx.net> In-Reply-To: <492C80BF.4010103@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 Carl-Daniel Hailfinger wrote: > 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. > This is pretty reasonable. > - 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". > Yes, I saw this patch but since it's just debugging code, it's not interesting for inclusion. > -- 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. > I'm concerned that modeling this could have a non negligible overhead and could be very difficult in something like KVM. Can you describe exactly what coreboot is expecting that we are not implementing? How is it relying on cache locking? > - 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. > BTW, I'd love to switch to something like coreboot but the legacy BIOS support payload is too incomplete. SeaBIOS is a good option too but it needs some heavy regression testing first. > I'm willing to do most of the work if I know that this won't be rejected > outright. > In general, better modeling of processor modes, provided that there isn't a regression in performance, is a good thing. Dividing the effort into incremental bits that are posted early for inclusion is also a good thing. Regards, Anthony Liguori > Regards, > Carl-Daniel > > >