Re: [Qemu-devel] Funny -m arguments can crash

[Blue Swirl]

On Mon, Aug 13, 2012 at 2:10 PM, Gleb Natapov <address@hidden> 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.