From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MgLlE-0004sz-9X for qemu-devel@nongnu.org; Wed, 26 Aug 2009 12:54:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgLlC-0004sI-LR for qemu-devel@nongnu.org; Wed, 26 Aug 2009 12:54:11 -0400 Received: from [199.232.76.173] (port=42693 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgLlC-0004rY-AR for qemu-devel@nongnu.org; Wed, 26 Aug 2009 12:54:10 -0400 Received: from ey-out-1920.google.com ([74.125.78.148]:47026) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MgLl9-0005rA-Lj for qemu-devel@nongnu.org; Wed, 26 Aug 2009 12:54:08 -0400 Received: by ey-out-1920.google.com with SMTP id 13so81991eye.14 for ; Wed, 26 Aug 2009 09:53:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Wed, 26 Aug 2009 19:53:39 +0300 Message-ID: Subject: Re: [Qemu-devel] memory restriction in 256M - why? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: Sergey Anosov , qemu-devel@nongnu.org On Wed, Aug 26, 2009 at 12:29 PM, Artyom Tarasenko wrote: > 2009/8/25 Sergey Anosov : >> I'm new in QEMU. I've got one question - why there is a memory restricti= on in 256 M on sparc, mips and other platforms? >> I've made mips and sparc distributives, but 256M of RAM is too little fo= r 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) =C2=A0wouldn't know where to searc= h > 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.