sparc32 machine specific maximums

This patch sets the maximum number of CPUs and memory to what is supported by the actual hardware.

Index: hw/sun4m.c
===================================================================
RCS file: /sources/qemu/qemu/hw/sun4m.c,v
retrieving revision 1.66

diff -p -u -r1.66 sun4m.c
@@ -82,6 +82,7 @@ struct hwdef {
     uint32_t intbit_to_level[32];
     uint64_t max_mem;
     const char * const default_cpu_model;
+    unsigned int max_cpus;
 };
 
 /* TSC handling */

@@ -345,10 +346,16 @@ static void sun4m_hw_init(const struct h
     if (!cpu_model)
         cpu_model = hwdef->default_cpu_model;
 
+    if (smp_cpus > hwdef->max_cpus) {
+        fprintf(stderr, "qemu: Too many CPUs for this machine: %d, maximum %d\n",
+                smp_cpus, hwdef->max_cpus);
+        exit(1);
+    }
+
     for(i = 0; i < smp_cpus; i++) {
         env = cpu_init(cpu_model);
         if (!env) {
-            fprintf(stderr, "Unable to find Sparc CPU definition\n");
+            fprintf(stderr, "qemu: Unable to find Sparc CPU definition\n");
             exit(1);
         }
         cpu_sparc_set_id(env, i);

@@ -514,8 +521,9 @@ static const struct hwdef hwdefs[] = {
             2, 3, 5, 7, 9, 11, 0, 14,   3, 5, 7, 9, 11, 13, 12, 12,
             6, 0, 4, 10, 8, 0, 11, 0,   0, 0, 0, 0, 15, 0, 15, 0,
         },
-        .max_mem = 0x10000000,
+        .max_mem = 0x10000000, // 256M (8 32M SIMMs)
         .default_cpu_model = "Fujitsu MB86904",
+        .max_cpus = 1,
     },
     /* SS-10 */
     {

@@ -550,8 +558,9 @@ static const struct hwdef hwdefs[] = {
             2, 3, 5, 7, 9, 11, 0, 14,   3, 5, 7, 9, 11, 13, 12, 12,
             6, 0, 4, 10, 8, 0, 11, 0,   0, 0, 0, 0, 15, 0, 15, 0,
         },
-        .max_mem = 0xffffffff, // XXX actually first 62GB ok
+        .max_mem = 0x20000000, // 512M (8 64M SIMMs)
         .default_cpu_model = "TI SuperSparc II",
+        .max_cpus = 4,
     },
     /* SS-600MP */
     {

@@ -586,8 +595,9 @@ static const struct hwdef hwdefs[] = {
             2, 3, 5, 7, 9, 11, 0, 14,   3, 5, 7, 9, 11, 13, 12, 12,
             6, 0, 4, 10, 8, 0, 11, 0,   0, 0, 0, 0, 15, 0, 15, 0,
         },
-        .max_mem = 0xffffffff, // XXX actually first 62GB ok
+        .max_mem = 0x40000000, // 1G (64 16M SIMMs)
         .default_cpu_model = "TI SuperSparc II",
+        .max_cpus = 4,
     },
 };
 

While it's not historically accurate to emulate a Sparcstation 5 with 16 CPUs and 2 gigabytes of memory, it doesn't break anything to have this capability. We don't throttle the power of the CPU, speed of the network, serial or disk devices either, so they may be unrealistically fast. The timers are not accurate at all compared to CPU execution speed.

Currently the memory on SS-5 machine is limited by the location of IOMMU and that the memory lies in one linear bank starting from zero. With more advanced banking and >4G patches, the entire physical address space could be filled with RAM.

I would be surprised if an SMP kernel actually worked on a multi CPU SS5. Currently OSs like solaris and bsd that actually use more than a minimal amount of hardware don't work in QEMU. That's because QEMUs system emulation is both incomplete and inaccurate. If you want to make a 16 CPU, 64 Gb machine, define a QEMU specific machine. There are no real 32 bit sparc systems like that. I would like to see real sun openboot ROM images work on realistic emulated hardware so QEMU could be used for real OS development.

Prepare for a surprise:

Loading initial ramdisk....
PROMLIB: obio_ranges 1
Booting Linux...
PROMLIB: Sun Boot Prom Version 3 Revision 2
Linux version 2.2.20pre2 (root@goretex) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Wed May 30 10:44:52 PDT 2001
ARCH: SUN4M
TYPE: SPARCstation 5
Ethernet address: 52:54:0:12:34:56
Boot time fixup v1.6. 4/Mar/98 Jakub Jelinek ([email protected]). Patching kernel for srmmu[Fujitsu TurboSparc]/iommu
[0]: v[f0000000,fd000000](d000000) p[00000000]
[1]: v[ed000000,eff2c000](2f2c000) p[0d000000]
Found CPU 0 <node=ffd56998,mid=0>
Found CPU 1 <node=ffd56d4c,mid=1>
Found CPU 2 <node=ffd57100,mid=2>
Found CPU 3 <node=ffd574b4,mid=3>
Found 4 CPU prom device tree node(s).
Power off control detected.
Calibrating delay loop... 235.92 BogoMIPS
Memory: 254792k available (1508k kernel code, 3372k data, 148k init) [ed000000,fd000000]
Dentry hash table entries: 32768 (order 6, 256k)
Buffer cache hash table entries: 262144 (order 8, 1024k)
Page cache hash table entries: 65536 (order 6, 256k)
VFS: Diskquotas version dquot_6.4.0 initialized
POSIX conformance testing by UNIFIX
Entering SMP Mode...
Starting CPU 1 at f01c9dc4
Calibrating delay loop... 84.17 BogoMIPS
Starting CPU 2 at f01c9dd0
Calibrating delay loop... 77.00 BogoMIPS
Starting CPU 3 at f01c9ddc
Calibrating delay loop... 78.84 BogoMIPS
Total of 4 Processors activated (475.95 BogoMIPS).
IOMMU: impl 0 vers 4 page table at efe80000 of size 524288 bytes
sbus0: Clock 21.1250 MHz
dma0: Revision 2
dma1: Revision 0
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0 for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
TCP: Hash tables configured (ehash 262144 bhash 65536)
Linux IP multicast router 0.06 plus PIM-SM
Initializing RT netlink socket
Starting kswapd v 1.5
Sparc Zilog8530 serial driver version 1.41.2.8
tty00 at 0xffe97004 (irq = 44) is a Zilog8530
tty01 at 0xffe97000 (irq = 44) is a Zilog8530
tty02 at 0xffe98004 (irq = 44) is a Zilog8530
tty03 at 0xffe98000 (irq = 44) is a Zilog8530
Sun TYPE 4 keyboard detected without keyclick
Console: ttyS0 (Zilog8530)
pty: 512 Unix98 ptys configured
Sun Mouse-Systems mouse driver version 1.00
RAM disk driver initialized: 16 RAM disks of 5120K size
Floppy drive(s): fd0 is 1.44M
FDC 0 is a S82078B
md driver 0.36.6 MAX_MD_DEV=4, MAX_REAL=8
linear personality registered
raid0 personality registered
raid1 personality registered
raid5 personality registered
esp0: IRQ 36 SCSI ID 7 Clk 40MHz CCF=8 TOut 167 NCR53C90(esp100)
ESP: Total of 1 ESP hosts found, 1 actually in use.
scsi0 : Sparc ESP100 (NCR53C90)
scsi : 1 host.
Vendor: QEMU Model: QEMU HARDDISK Rev: 0.9.
Type: Direct-Access ANSI SCSI revision: 03
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
Vendor: QEMU Model: QEMU CD-ROM Rev: 0.9.
Type: CD-ROM ANSI SCSI revision: 03
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 2, lun 0
scsi : detected 2 SCSI generics 1 SCSI cdrom 1 SCSI disk total.
sr0: scsi3-mmc drive: 16x/50x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.11
SCSI device sda: hdwr sector= 512 bytes. Sectors= 2097152 [1024 MB] [1.0 GB] Partition check:
sda: sda1 sda2 sda3
RAMDISK: Compressed image found at block 0
EXT2-fs warning: checktime reached, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
serial console detected. Disabling virtual terminals.
init started: BusyBox v0.51 (2001.05.24-01:20+0000) multi-call binary none on /proc type proc (rw)
chown[26]: Unimplemented SPARC system call 31
chown[38]: Unimplemented SPARC system call 31

Please give concrete examples where the emulation is incomplete so we can fix the problems. There are some well known areas where Qemu is by design not accurate and some things are hard to implement.

I can't imagine anybody forcing someone to put -smp 16 -m 64000 to the command line.

How exactly does the _capability_ to specify more than 256M of memory or more than one CPU break your ROM?

That's interesting because the fact that it works shows how inaccurate the emulation is.

Now could you please really surprise me by booting Solaris 2.5 using a real sun openprom image ;-)

This wonder is not possible because of the any inaccuracies, it's possible because there is an Open Firmware abstraction layer between the OS and hardware. If more CPUs are available, Linux just starts them using the OF interface. Linux can't check whether the system is physically capable of containing more CPUs, it can merely check that the platform is Sun4m, which is fully SMP capable.

The interface between OF and hardware is not completely documented (SMP) and Qemu is by design not completely suitable to emulate everything that the real prom wants, like caches, performance counters or test/debug modes. Therefore I'm more interested in booting Solaris using OpenBIOS image. While the interface between OF and Solaris is documented, the assumptions used by Solaris aren't.

But I'd be happy to fix bugs or implement the missing details to either Qemu or OpenBIOS that help Solaris boot.

I believe the Cray CS6400 was a 64-way sparc32 machine with 16Gb ram. Admittedly it's a sun4d variant, not sun4m. I've no idea how much difference (if any) that makes to OS.

Paul

Sun4d is not that different from Sun4m. Interrupt handling is different. There are several IOUNITs in place of the single IOMMU, but they use the same page tables. The rest of the devices are the same old stuff. One (Linux) kernel can be used for all of Sun4c, Sun4m, and Sun4d.

I think Linux doesn't support more than 4G of memory even on Sun4d.

I have a preliminary patch to implement SS-1000 and SS-2000. If I find docs for Cray CS6400, I'd be interested to implement that as well.

Are you sure? OS kernels, let alone Model-specific firmware images, may well have intimate knowledge about the specific machine layout.

Implementing a different machine than the one announced sounds like bad idea to me, especially when modelling an additional hypothetical machine variant in QEMU is so cheap to implement.

Thiemo

The boot prom (OpenBoot Prom/Open Firmware) must know, but the OS need not know so much. For example, the OS calls OF to start a new CPU. On OpenBIOS, this is handled by sending an interrupt to the halted CPU. I don't know how the real ROM works, there are no docs for these things. I'd be happy to change this to match the real hardware if someone tells me how. Likewise for memory, OS just reads a few tables giving the available and unavailable physical and virtual memory addresses.

I can't see how adding more CPUs or memory can break anything. It works well, because of the indirection provided by the boot prom (OpenBIOS in our case). Maybe the real ROM can't understand the extra CPUs or memory, but who cares? Just reduce CPUs and memory if you want to use real ROM.

Am 04.12.2007 um 00:53 schrieb Thiemo Seufer:

Unfortunately such fprintf messages to stderr are only visible on the console and not in graphical frontends. If you decide to place more of those abort messages, could you please consider using macros so they can be easily overridden with message boxes or some other notification mechanism?

Andreas