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. 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? Regards, Carl-Daniel -- http://www.hailfinger.org/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
