From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Release plan for 0.12.0 Date: Wed, 30 Sep 2009 08:07:26 -0500 Message-ID: <4AC3580E.4010505@us.ibm.com> References: <4AC29E4D.80707@us.ibm.com> <4AC3257A.7060003@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "qemu-devel@nongnu.org" , Paul Brook , kvm-devel To: Carl-Daniel Hailfinger Return-path: Received: from e39.co.us.ibm.com ([32.97.110.160]:58840 "EHLO e39.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753046AbZI3NHs (ORCPT ); Wed, 30 Sep 2009 09:07:48 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e39.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8UD2DAB000928 for ; Wed, 30 Sep 2009 07:02:13 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8UD7YsC135828 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 n8UD7Wfa026518 for ; Wed, 30 Sep 2009 07:07:34 -0600 In-Reply-To: <4AC3257A.7060003@gmx.net> Sender: kvm-owner@vger.kernel.org List-ID: 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