From: "Blue Swirl" <blauwirbel@gmail.com>
To: Thiemo Seufer <ths@networkno.de>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums
Date: Tue, 4 Dec 2007 18:26:07 +0200 [thread overview]
Message-ID: <f43fc5580712040826p92f4741p67834a95d6832a55@mail.gmail.com> (raw)
In-Reply-To: <20071203235341.GK617@networkno.de>
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.
next prev parent reply other threads:[~2007-12-04 16:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-02 23:12 [Qemu-devel] [PATCH] sparc32 machine specific maximums Robert Reif
2007-12-03 17:25 ` Blue Swirl
2007-12-03 23:41 ` Robert Reif
2007-12-04 16:12 ` Blue Swirl
2007-12-04 23:30 ` Robert Reif
2007-12-06 17:37 ` Blue Swirl
2007-12-04 17:26 ` Paul Brook
2007-12-04 18:40 ` Blue Swirl
2007-12-03 23:53 ` Thiemo Seufer
2007-12-04 16:26 ` Blue Swirl [this message]
2007-12-04 16:30 ` Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f43fc5580712040826p92f4741p67834a95d6832a55@mail.gmail.com \
--to=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=ths@networkno.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).