qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Release plan for 0.12.0


From: Anthony Liguori
Subject: Re: [Qemu-devel] Release plan for 0.12.0
Date: Wed, 30 Sep 2009 08:07:26 -0500
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]