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