Re: netbsd-5.1 cpu probe/attach for 11/7xx?

[Johnny Billquist <bqt%softjar.se@localhost>]

On 2011-06-26 04.00, der Mouse wrote:
> > > > Older VAXen don't really have a CPU attach function.  There can
> > > > only be one CPU, and it is implicitly already attached.
> > > NetBSD/vax doesn't support the 782?
> > Right.  The 782 is not supported.  It is in fact rather tricky, if we
> > were ever to support it, since it's not an SMP machine.  The second
> > CPU acts as a slave to the first one.  They are not equal.  The
> > second CPU can only do computations, and have no I/O attached to it.
>
> Aren't a lot of multiprocessor machines asymmetric in that sort of way?
> For example, only one CPU can field interrupts?

Hmm. Well, I can't really say. The MP machines I've worked on have been 
much more SMP than the 11/782 is. But it's true that few machines are 
truly symmetric. There is usually some CPU which is a little special.

I must admit that I'm not totally aware of how the hardware works in the 
11/782. I only know how VMS ran on that machine, and as far as I know, 
only VMS supported it. But for VMS, the secondary CPU was scheduled by 
the primary CPU. It did not run the OS at all. Instead, the primary CPU 
scheduled the secondary, and whenever something significant happened for 
the process controlled by the secondary CPU, it just interrupted the 
primary, who had to deal with it. And the secondary CPU then waited for 
some new work to be scheduled for it by the primary CPU. The machine did 
have shared memory, but apart from that, I'm not sure how the 
communication between the CPUs were done. Some sort of way for the 
secondary to interrupt the primary existed, and some way for the primary 
to feed information to the secondary for it to start work, but I lack 
more detail. (I bet it exists somewhere though, if we really want to 
figure this out...)

> 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.  (Not all device interrupts; some devices, such
> as console serial ports, exist on each CPU board and interrupt the CPU
> whose board they're on.)

Well, not really that simple. There are no IDs for devices on a Qbus. If 
you wanted to have a second CPU on the Qbus, you need to remove the bus 
termination and bus arbitration from that CPU, since you cannot have two 
bus arbitrators. And as far as I know, the KA630 don't have a way to 
actually do that disabling.
Also, the uVAX II have the memory on PMI, which is separate from the 
Qbus, so a second CPU cannot access the memory of the primary CPU. This 
is the difference from the uVAX I, which actually had memory on the Qbus 
(that also limited the memory to 4MB on the uVAX I).

> It was difficult to get a KA-630 without a MicroVAX around it, becaus
> DEC didn't want knock-off Qbus backplanes furnished with KA630s and
> sold as cheap MicroVAXen.  (The KA620 was their answer to that; I don't
> recall whether NetBSD supports the KA620.  It would probably be easy to
> add if not; it was a minor tweak.)  I know a bit about this because a
> reseacher I was supporting once wrote a robot control system where the
> control law ran on an auxiliary KA620 - and I wrote the kernel for the
> auxiliary CPU.

I have actually never seen or heard of a MP KA630, but if you have some 
real references, it would be interesting. I looked up the KA620, and it 
might be that this model was designed with the possibility to have 
several on a single Qbus, but it is a bit unclear. I'm also not sure how 
you dealt with interprocessor communication in this case. I suspect the 
KA620 used normal Qbus memory, but how would one CPU interrupt another one?

KA630 cpu boards exists in ridiculous numbers nowadays, you know... ;-)

> > There is in fact no VAX which have a Unibus as the native bus.  The
> > closest would be the uVAX I, which have the Qbus as the system bus.
> > But that's the only one.
>
> What did the uV2 have?  Certainly from a user's perspective the Qbus
> was the system bus there; are you considering there to be a memory bus
> on the CPU board which the CPU, RAM, and Qbus all hang off of?

RAM does not sit on the Qbus. Remember, the Qbus can only address 4MB. 
You have a Unibus map (well, I guess it should be called a Qbus map in 
this case) between the Qbus and memory, while the CPU talks to memory 
through PMI.

There is no official name for whatever bus is closest to the CPU on the 
uVAX II, and since that bus is internal to the CPU card, it's easy to 
regard the machine as a Qbus machine, but looking closer, it is pretty 
obvious that it's not really true that the Qbus is the system bus. The 
Qbus is just an I/O bus for the uVAX II.

I think that in NetBSD we call it "VSBUS" for lack of a better name.

> Certainly from a multiprocessing perspective, the Qbus was the main
> interconnect; for one CPU to get the attention of another required a
> Qbus cycle.  (Each CPU had its own memory interconnect; the only way to
> share memory between CPUs, as far as I know, was over the Qbus.  This
> was a bit of a pain, because it meant that for every byte of memory,
> one CPU had fast access to it and everybody else had slow, or no,
> access.)

That would also imply DMA access to get to another CPUs memory, running 
through that CPUs mapping registers, and so on. 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. The fiddling to pull this off is more than I want to think 
of, if at all possible. Such an I/O page access on the Qbus is not the 
same as a DMA memory access by some other device on the Qbus, so I very 
much doubt the other CPUs memory mapping and response would be 
activated. And you'd still need to avoid your own CPU to react to those 
accesses. Besides, you then also need to make the CPU respond to a whole 
range of addresses up high. 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?

        Johnny