[Qemu-devel] Modeling x86 early initialization accurately

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

Hi,

current svn HEAD of QEMU assumes all RAM is available directly at x86
CPU startup. The ability to lock processor caches to function as RAM
(Cache-as-RAM) is unimplemented as well.
While that does make it easier for the shipped BIOS to set up working
RAM (i.e. it does nothing about that right now), that simplification
reduces the ability to run alternative firmwares for x86 in QEMU.
coreboot (a free x86 firmware/BIOS replacement) is unable to use
standard x86 early initialization because the MSRs for cache control
(MTRRs) are completely unimplemented and ignored.
Modeling ACPI S3 (Suspend-to-RAM) suffers from similar issues.

Things which need to be changed to model x86 better:
- Start up with all RAM being readonly. Writes should be discarded,
reads will usually return 0xff or be undefined. The "undefined" variant
would allow the code to allocate RAM once and just switch write access
on/off.
- Support MTRRs.
-- Mention MTRR support in CPUID.
-- I sent a patch to dump unknown MSR accesses in general and MTRR
reads/writes in particular. The subject was "[Qemu-devel] [PATCH] x86
MTRR access dumping".
-- It is not really needed to completely implement L1/L2 caches, but the
ability to lock the cache with the help of MTRRs should be available.
Areas with active locked cache do not send writes down to the RAM which
is still readonly. The cache locking is done on a per-page basis (or
even larger granularity), so it should be easier than having to handle
single cache lines.
- Decide what to do for RAM initialization. Do we switch RAM into
read-write mode by a simple QEMU-specific MSR write? Do we want to
implement all memory initialization hardware instead?
- Adapt the currently shipped BIOS to these tasks and/or switch to
coreboot+SeaBIOS.

I'm willing to do most of the work if I know that this won't be rejected
outright.


Regards,
Carl-Daniel