On Mon, Aug 13, 2012 at 2:10 PM, Gleb Natapov <g...@redhat.com> wrote: > On Mon, Aug 13, 2012 at 05:04:30PM +0300, Avi Kivity wrote: >> On 08/13/2012 05:02 PM, Gleb Natapov wrote: >> >> >> IMO we need to fix CMOS reporting. >> >> >> >> (technically we shouldn't touch CMOS NVRAM at all; seabios should >> >> discover memory size via fwcfg and program it itself. But it's >> >> pointless to change it now) >> >> >> > Chipset we emulate does not support all those crazy memory values you >> > can give to -m. >> >> Our chipset is a 440fx enhanced with fwcfg and other goodies, not a >> plain 440fx. >> > It has registers to program DIMM slots configs. fwcfg does not enhanced > it in any way. And you cannot program more than 4G memory there may be > even less. So what do you mean by "program it itself"? Program CMOS > itself? (What for? QEMU does not care). Or program 440fx DIMM config?
An idealistic emulator would not have an fw_cfg but it would let BIOS discover everything, exactly like a real BIOS would do. It would also support using BIOS ROM images from real 440fx machine. This approach, taken to its extreme, would eventually lead to an cycle accurate emulator, it would emulate various chip erratas and probably become a very slow monster. However, the approach which we have taken in QEMU is that performance is more important than uselessly exact emulation and the OSes don't care what is the exact interface between BIOS and HW. Thus we can take a few PV shortcuts. Modeling the RAM as linear area with any integer amount of MB has taken us pretty far, but modeling the DIMM slots can still be interesting because it gives better emulation without performance loss. Modeling what happens if CAS latency programming is off limits would not be interesting for QEMU. > >> But it's true it probably doesn't support 82.66642kB RAM. > > It does not support much less exotic 4G. > > -- > Gleb.
