[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: netbsd-5.1 cpu probe/attach for 11/7xx?
On 2011-06-26 05.17, der Mouse wrote:
But for VMS [on the -11/782], the secondary CPU was scheduled by the
primary CPU. It did not run the OS at all. Instead, [...]
Of course, the real question is, how much of this was imposed by the
hardware and how much is just how VMS happened to use it; just because
the hardware is (almost) symmetric does not necessarily mean software
will use it symmetrically.
Exactly. I have the vague idea that the possibility to interrupt the
other processor is not symmetric, but I can't find any documentation of
the 11/782 right now, so I don't know where I got this notion from.
Certainly the MicroVAX-II supported relatively symmetric
multiprocessing; as far as I can recall the only asymmetries there
are that the CPU at ID 0 (a) terminates the Qbus, (b) runs at
power-up instead of halting and waiting for another CPU to boot it,
and (c) gets Qbus device interrupts.
Well, not really that simple. There are no IDs for devices on a
No, but there are for MicroVAX-II CPUs. There can be up to four of
them per Qbus; for the KA630 and KA620, the ID bits are set by the
connector that on a main CPU runs to the back-panel plate with the
console DE9, speed switch, halt switch, etc. The usual back-panel
board sets those bits to ID 0, the distinguished CPU, but alternative
boards can set it to any of the other three (as can an ordinary board
with minimal surgery).
Ah! Thanks. I read through the user guide for the KA630. Fun stuff.
While it generally means that the KA630 was designed so that MP systems
can be done, it is not in general with shared memory. Instead, each
processor has its own memory, and you can share a small window of it.
Mostly thought to be used for message passing.
But you do indeed have four different CSRs reserved for the four CPUs,
so that they can knock on each other. And only the primary CPU gets
interrupts from the Qbus, although all CPUs gets other interrupts.
It also becomes even more weird, since memory access by one CPU does
not even go out on the Qbus, so you can only get access to another
CPUs memory by faking that you are accessing the I/O page of the
Qbus, which is a 8Kbyte memory in the high end.
I'm fairly sure there was a way to access more than 8K at a time, but
that is getting into things lost to the mists of memory.
After looking, you are right. As the CPU appears to be able to present
the private memory as Qbus memory. That sets the limit to 4MB. I wonder
if that is done through the same map as for DMA. Would seem logical.
And this has not at all solved the interrupt issues. If a device
field an interrupt, all CPUs would see it. How would you prevent all
but one CPU to ignore this?
I *think* this too is driven off the ID bits - an ID setting other than
00 disables the Qbus interrupt response circuitry. Again, I'd have to
check the doc to be sure.
No need. You remember right. It's controlled by those ID bits. They
select if arbitration is done, interrupt handling, and also the CSR
address for the CPU.
NUMA system, it would seem... :-) I wonder if NetBSD could be tricked
into handling such a machine.
Main Index |
Thread Index |