[Qemu-devel] memory restriction in 256M - why?

[Qemu-devel] memory restriction in 256M - why?

[Sergey Anosov]

Hi all!

I'm new in QEMU. I've got one question - why there is a memory restriction in 256 M on sparc, mips and other platforms?
I've made mips and sparc distributives, but 256M of RAM is too little for them. 
I have seen patch for versatile platform, that expands amount of physicall memory.
Is there such patches for mips and sparc?

Thanks.

Re: [Qemu-devel] memory restriction in 256M - why?

[Artyom Tarasenko]

2009/8/25 Sergey Anosov <aserg2004@list.ru>:
> I'm new in QEMU. I've got one question - why there is a memory restriction in 256 M on sparc, mips and other platforms?
> I've made mips and sparc distributives, but 256M of RAM is too little for them.

There is no such restriction:

qemu-system-sparc -M SS-10 -m 512
...
Probing Memory Bank #0 64 Megabytes of DRAM
Probing Memory Bank #1 64 Megabytes of DRAM
Probing Memory Bank #2 64 Megabytes of DRAM
Probing Memory Bank #3 64 Megabytes of DRAM
Probing Memory Bank #4 64 Megabytes of DRAM
Probing Memory Bank #5 64 Megabytes of DRAM
Probing Memory Bank #6 64 Megabytes of DRAM
Probing Memory Bank #7 64 Megabytes of DRAM
...

But there is a limitation per certain machine type. SparcStation 10
can support only 512 M. It rarely makes sense to try to put more in
it: a standard software (Firmware, OS)  wouldn't know where to search
for more RAM.

Re: [Qemu-devel] memory restriction in 256M - why?

[Stefan Weil]

Artyom Tarasenko schrieb:
> 2009/8/25 Sergey Anosov <aserg2004@list.ru>:
>   
>> I'm new in QEMU. I've got one question - why there is a memory restriction in 256 M on sparc, mips and other platforms?
>> I've made mips and sparc distributives, but 256M of RAM is too little for them.
>>     
>
> There is no such restriction:
>
> qemu-system-sparc -M SS-10 -m 512
> ...
> Probing Memory Bank #0 64 Megabytes of DRAM
> Probing Memory Bank #1 64 Megabytes of DRAM
> Probing Memory Bank #2 64 Megabytes of DRAM
> Probing Memory Bank #3 64 Megabytes of DRAM
> Probing Memory Bank #4 64 Megabytes of DRAM
> Probing Memory Bank #5 64 Megabytes of DRAM
> Probing Memory Bank #6 64 Megabytes of DRAM
> Probing Memory Bank #7 64 Megabytes of DRAM
> ...
>
> But there is a limitation per certain machine type. SparcStation 10
> can support only 512 M. It rarely makes sense to try to put more in
> it: a standard software (Firmware, OS)  wouldn't know where to search
> for more RAM.
>
>
>
>   

MIPS Malta is limited to 256 MiB. This is a hardware limitation
and not caused by QEMU.

Re: [Qemu-devel] memory restriction in 256M - why?

[Blue Swirl]

On Wed, Aug 26, 2009 at 12:29 PM, Artyom
Tarasenko<atar4qemu@googlemail.com> wrote:
> 2009/8/25 Sergey Anosov <aserg2004@list.ru>:
>> I'm new in QEMU. I've got one question - why there is a memory restriction in 256 M on sparc, mips and other platforms?
>> I've made mips and sparc distributives, but 256M of RAM is too little for them.
>
> There is no such restriction:
>
> qemu-system-sparc -M SS-10 -m 512
> ...
> Probing Memory Bank #0 64 Megabytes of DRAM
> Probing Memory Bank #1 64 Megabytes of DRAM
> Probing Memory Bank #2 64 Megabytes of DRAM
> Probing Memory Bank #3 64 Megabytes of DRAM
> Probing Memory Bank #4 64 Megabytes of DRAM
> Probing Memory Bank #5 64 Megabytes of DRAM
> Probing Memory Bank #6 64 Megabytes of DRAM
> Probing Memory Bank #7 64 Megabytes of DRAM
> ...
>
> But there is a limitation per certain machine type. SparcStation 10
> can support only 512 M. It rarely makes sense to try to put more in
> it: a standard software (Firmware, OS)  wouldn't know where to search
> for more RAM.

No, we limit the memory on SS-10/20/600MP to 60G, because we can make
contiguous RAM available up to that. We could support even more memory
if the additional RAM was added to ranges outside of MMIO, but then
the memory would no longer be contiguous and this would need support
from OpenBIOS.

It's true that the original SS-10 hardware (and original OpenBoot
roms) only supported 512M, so another approach would be to use the
historical limit.

Which approach is more correct depends on what you aim. QEMU is by
design not a cycle accurate emulator, so IMHO we have generally more
flexibility.

On Sparc32/64 and PPC, OpenFirmware also provides a level of
indirection that hides some details of the machine, so QEMU+OpenBIOS
can make shortcuts. For example, instead of probing the memory,
OpenBIOS reads the memory size directly from QEMU specific firmware
configuration device.

Linux will happily use all memory that the OpenFirmware interfaces
allow so the emulated machine usually runs faster.