Re: [Qemu-devel] Release plan for 0.12.0

[Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>]

On 30.09.2009 15:07, Anthony Liguori wrote:
> Carl-Daniel Hailfinger wrote:
>> However, to run coreboot on Qemu with the same init sequence as on
>> simplified real hardware, we need Cache-as-RAM (CAR) support. [...] 
>
> 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.

I know that some people were running 440BX BIOS images for real hardware
on Qemu and they got pretty far.

The complexity would be limited to the MTRR code and unless there were
major architectural changes in mapping RAM to address ranges, no other
code (except VM save and VM restore) should get even a single line changed.

>> 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.

It only runs if WORKAROUND_QEMU is defined (maybe not exactly that name,
but you get the point). The code in coreboot calculates MTRR settings to
cover the place where the stack will be. To workaround missing CAR in
Qemu, it then has to recalculate the stack location to be able to
actually use the stack. That forces coreboot to keep two stack base
variables and to completely replace the generic logic which switches off
CAR.

I hope the explanation above didn't offend you, I just tried to clarify
why working CAR is such a big deal for coreboot.

If you want either a full CAR implementation or no CAR implementation, I
can write a patch which implements full CAR, but then I need to hook
WBINVD, INVD and CLFLUSH. Neither instruction is executed often enough
to show up in any profile. Besides that, for anything not using CAR
(everything after the firmware), the penalty is a simple test of a
boolean variable per WBINVD/INVD/CLFLUSH.

If you have further questions, please don't hesitate to ask.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/