Re: [Qemu-devel] Modeling x86 early initialization accurately

[Anthony Liguori]

Carl-Daniel Hailfinger wrote:
> 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.
>   

This is pretty reasonable.

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

Yes, I saw this patch but since it's just debugging code, it's not 
interesting for inclusion.

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

I'm concerned that modeling this could have a non negligible overhead 
and could be very difficult in something like KVM.  Can you describe 
exactly what coreboot is expecting that we are not implementing?  How is 
it relying on cache locking?

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

BTW, I'd love to switch to something like coreboot but the legacy BIOS 
support payload is too incomplete.  SeaBIOS is a good option too but it 
needs some heavy regression testing first.

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

In general, better modeling of processor modes, provided that there 
isn't a regression in performance, is a good thing.  Dividing the effort 
into incremental bits that are posted early for inclusion is also a good 
thing.

Regards,

Anthony Liguori

> Regards,
> Carl-Daniel
>
>
>