Re: [Qemu-devel] Release plan for 0.12.0

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

 



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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux