Re: [Qemu-devel] [PATCH] CMOS file support

[Mathias Krause <mathias.krause@secunet.com>]

On 17.09.2010 12:58, Stefan Weil wrote:
> Am 17.09.2010 08:42, schrieb Mathias Krause:
>> Am 16.09.2010 18:49, Stefan Weil schrieb:
>>> Are there use cases where having a smaller CMOS size is better?
>>> For example, when I want to emulate a system with 128 byte CMOS?
>>> The size of CMOS could be derived from the size of the data
>>> or specified by an additional parameter.
>>
>> I cannot image cases where smaller sizes would be a benefit. The saved
>> disk space is negligible and you can always pad your CMOS configuration
>> uo to 256 bytes by filling the gap with zero bytes. If the system just
>> accesses the first 128 bytes the additional 128 zero bytes shouldn't
>> hurt.
>>
> 
> The benefit of smaller sizes is not saving RAM but precision
> of the emulation.

Well, as mentioned in my initial email the current emulation isn't
accurate as well. It is emulating 128 bytes of CMOS RAM instead of 64
bytes, the real MC146818 only has.

> A BIOS or an operating system might be designed to support
> CMOS  with 128 bytes or 256 bytes and try guessing the size
> by probing (many systems do something like this for RAM or
> other memory types).
> 
> Testing the support of the small CMOS will be impossible
> if the emulation always emulates 256 bytes. Filling the
> additional 128 bytes with zero bytes won't help because
> the system will access them successfully although writes
> should fail.

To access the upper 128 bytes of memory the operation system must be
aware that it needs to use different I/O ports to probe for those
addresses. The patch doesn't change the old behavior. Only the lower 128
bytes of memory will be accessible through the default RTC ports.
So if the operating system or BIOS in question already is aware of the
alternative method to access the upper 128 bytes, why should if fail then?