On Wed, Sep 30, 2009 at 6:59 PM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@xxxxxxx> wrote: > 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. The CAR mode could affect only translation so that special CAR versions of the WBINVD etc. instructions are selected. On switch to normal mode, the TBs need to be flushed. Instead of your memory mapping approach (which should work) you could also try using different memory access functions in CAR mode. It may be more difficult, though. -- 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
