[Qemu-devel] [PATCH] sparc32 machine specific maximums

[Qemu-devel] [PATCH] sparc32 machine specific maximums

[Robert Reif]

[-- Attachment #1: Type: text/plain, Size: 100 bytes --]

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

[-- Attachment #2: max.diff.txt --]
[-- Type: text/plain, Size: 2331 bytes --]

Index: hw/sun4m.c
===================================================================
RCS file: /sources/qemu/qemu/hw/sun4m.c,v
retrieving revision 1.66
diff -p -u -r1.66 sun4m.c
--- hw/sun4m.c	2 Dec 2007 04:51:10 -0000	1.66
+++ hw/sun4m.c	2 Dec 2007 23:03:18 -0000
@@ -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,
     },
 };
 

Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums

[Blue Swirl]

On 12/3/07, Robert Reif <reif@earthlink.net> wrote:
> This patch sets the maximum number of CPUs and memory to what is
> supported by the actual hardware.

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.

Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums

[Robert Reif]

Blue Swirl wrote:

>On 12/3/07, Robert Reif <reif@earthlink.net> wrote:
>  
>
>>This patch sets the maximum number of CPUs and memory to what is
>>supported by the actual hardware.
>>    
>>
>
>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.

Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums

[Thiemo Seufer]

Blue Swirl wrote:
> On 12/3/07, Robert Reif <reif@earthlink.net> wrote:
> > This patch sets the maximum number of CPUs and memory to what is
> > supported by the actual hardware.
> 
> 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.

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

Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums

[Blue Swirl]

On 12/4/07, Robert Reif <reif@earthlink.net> wrote:
> Blue Swirl wrote:
>
> >On 12/3/07, Robert Reif <reif@earthlink.net> wrote:
> >
> >
> >>This patch sets the maximum number of CPUs and memory to what is
> >>supported by the actual hardware.
> >>
> >>
> >
> >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.

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 (jj@ultra.linux.cz).
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

> 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

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.

> 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

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

> images work on realistic emulated hardware so QEMU could be used for
> real OS development.

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

Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums

[Blue Swirl]

On 12/4/07, Thiemo Seufer <ths@networkno.de> wrote:
> Blue Swirl wrote:
> > On 12/3/07, Robert Reif <reif@earthlink.net> wrote:
> > > This patch sets the maximum number of CPUs and memory to what is
> > > supported by the actual hardware.
> >
> > 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.
>
> Are you sure? OS kernels, let alone Model-specific firmware images,
> may well have intimate knowledge about the specific machine layout.

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.

> 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.

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.

Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums

[Andreas Färber]

Am 04.12.2007 um 00:53 schrieb Thiemo Seufer:

> Blue Swirl wrote:
>> On 12/3/07, Robert Reif <reif@earthlink.net> wrote:
>>> This patch sets the maximum number of CPUs and memory to what is
>>> supported by the actual hardware.
>>
>> 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.
>
> 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.

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

Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums

[Paul Brook]

> 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 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

Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums

[Blue Swirl]

On 12/4/07, Paul Brook <paul@codesourcery.com> wrote:
> > 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 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.

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.

Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums

[Robert Reif]

Blue Swirl wrote:

>On 12/4/07, Robert Reif <reif@earthlink.net> wrote:
>  
>
>>I would be surprised if an SMP kernel actually worked on a multi CPU SS5.
>>    
>>
>
>Prepare for a surprise:
>
>  
>
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 ;-)

Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums

[Blue Swirl]

On 12/5/07, Robert Reif <reif@earthlink.net> wrote:
> Blue Swirl wrote:
>
> >On 12/4/07, Robert Reif <reif@earthlink.net> wrote:
> >
> >
> >>I would be surprised if an SMP kernel actually worked on a multi CPU SS5.
> >>
> >>
> >
> >Prepare for a surprise:
> >
> >
> >
> That's interesting because the fact that it works shows how inaccurate
> the emulation is.

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.

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

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.