qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums
Date: Tue, 4 Dec 2007 18:26:07 +0200

On 12/4/07, Thiemo Seufer <address@hidden> wrote:
> Blue Swirl wrote:
> > On 12/3/07, Robert Reif <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]