From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MsyuJ-0001kF-IE for qemu-devel@nongnu.org; Wed, 30 Sep 2009 09:07:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MsyuE-0001fG-Qa for qemu-devel@nongnu.org; Wed, 30 Sep 2009 09:07:47 -0400 Received: from [199.232.76.173] (port=53121 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsyuE-0001f3-FJ for qemu-devel@nongnu.org; Wed, 30 Sep 2009 09:07:42 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:55005) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MsyuD-0007cL-Uo for qemu-devel@nongnu.org; Wed, 30 Sep 2009 09:07:42 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8UD2qiB014071 for ; Wed, 30 Sep 2009 07:02:52 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8UD7YRm216228 for ; Wed, 30 Sep 2009 07:07:35 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8UD7WfY026518 for ; Wed, 30 Sep 2009 07:07:34 -0600 Message-ID: <4AC3580E.4010505@us.ibm.com> Date: Wed, 30 Sep 2009 08:07:26 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Release plan for 0.12.0 References: <4AC29E4D.80707@us.ibm.com> <4AC3257A.7060003@gmx.net> In-Reply-To: <4AC3257A.7060003@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Carl-Daniel Hailfinger Cc: "qemu-devel@nongnu.org" , kvm-devel , Paul Brook Carl-Daniel Hailfinger wrote: > Hi, > > On 30.09.2009 01:54, Anthony Liguori wrote: > >> Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. >> >> I'd also like to try to enumerate some features for this release. >> Here's a short list of things I expect to see for this release >> (target-i386 centric). >> >> o switch to SeaBIOS (need to finish porting features from Bochs) >> > > That switch is much appreciated because it also reduces the testing > matrix of those coreboot developers who boot test every commit with Qemu. > > However, to run coreboot on Qemu with the same init sequence as on > simplified real hardware, we need Cache-as-RAM (CAR) support. This is > basically a mode where sizeof(cacheable area) <= sizeof (L2 cache) and > causes the processor to lock the cache and not pass any reads/writes > through to the RAM behind the cached area. The easiest way to implement > this would be to check the cache size criterion upon every MTRR > manipulation and either map a chunk of fresh memory on top of the > existing memory (which may be RAM, ROM or unmapped) for every cacheable > area, and if the cacheable area starts to exceed the L2 cache size, > discard all memory contents of the memory mapped on top. > For additional correctness, the memory shoud not be discarded and > written back to the lower layer of memory if WBINVD (instead of INVD) or > CLFLUSH are called. That one is mostly sugar, though, and coreboot can > do without. > Do we really need coreboot to use the same init sequence? coreboot is firmware and we don't necessarily run real firmware under QEMU. It's a short cut that lets us avoid a lot of complexity. > Right now coreboot sets up the MTRRs correctly, but then (conditional on > Qemu) only uses areas which are known to be backed by RAM instead of the > areas designated by CAR. > > I'd like to implement CAR support which builds on top of my MTRR code > which was merged some months ago (and I already have code to check for > total cacheable area size), but I need help with the memory mapping > stuff. How do I proceed? Clean up what I have and insert "FIXME" > comments where I don't know how to implement stuff so others can see the > code and comment on it? > You could start there. But from a higher level, I'm not sure I think a partial implementation of something like CAR is all that valuable since coreboot already runs under QEMU. > Regards, > Carl-Daniel > > -- Regards, Anthony Liguori