Port-vax archive

[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 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,

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?


Home | Main Index | Thread Index | Old Index