Peter Hunkler:
What I'm about to say does not contradict Peter Relson's post
clarifying things relative to MVS -> z/OS.
Unless IBM has done some interesting magic, the c-store of a
z/Architecture box is "owned" by the Hypervisor, in this case
PR/SM. There are no bare metal SCPs today because of how IBM does
things.
Now, going back > 20 years for an Amdahl 5990, MDF started at low
storage, and self-relocated to high storage (HSA) -- very early
in the process. Absolute 0 was still at absolute 0. Meanwhile the
580s' HSA was low storage if I remember correctly.
Within the Hypervisor, once the MP init (Multi-Processor) was
done, all the CPUs were prefixed into HSA (which belongs to the
hypervisor).
At some point, domain init gets run, and the domains get built
(IBM's LPARs). They start off with a pseudo absolute 0 which is
at the bottom of their storage block. So you do an IPL (for the
SCP for that domain), and the SCP loads, and at some point (MVS
or VM) MP INit is done, now the domain (again, LPAR in IBM
parlance) "prefixes" all of the CPUs it knows about.
After that SCP gets virtual storage controls initialized, DAT
becomes is functional. Depends on the SCP as to how soon this is
completed.
So, here you are with VM and SIE. You now have virtual storage
run by VM (CP) to the second level machine which may be REAL or
may be a Virtual system as well.
Eyes glazed over yet?
To effect all of this, the CEC must implement some kind of
Hypervisor Registers (probably at the CPU level) so that one can
switch between DOMAIN/LPAR mode and Hypervisor mode and address
storage accordingly.
When VM/CP are functioning, it must do the same kind of tracking
for each of its guests.
Wanna have some more fun? The hardware has just detected a
double-bit parity error. How will you reflect that MCK to the
affected LPAR?
The Hypervisor is the one that gets posted with that. And now it
has to figure out where that CPU was in the grand scheme of
things so that the MCK can be handled correctly. I used to do
that level of programming at Amdahl.
So, one finds what the domain registers contained, and then you
do the MCK PSW swap after setting all the bits/etc. in that CPU's
Prefix area in that domain (LPAR), and let that SCP figure it out
-- depending on whether it was exigent or repressive and the CR
bits were set...
And we haven't even mentioned I/O in all of this other than to
hint at it because of "IPL".
It gets complicated. And when Amdahl started this (MDF) IBM's
machines were still Base 370, and some engineers had to figure
out how to float I/O 'rupts so they could be reflected to the
correct CPU in the correct Domain. Plus, page fixing and getting
I/O synced with the right channel.... Having X/A channels would
have made this much easier.... I just wonder who came up with
that idea.
(If I'm a bit off, forgive me, it has been a bit over 20 years
since I did this level of programming, and with CMOS a lot
changed that I was never part of).
Regards,
Steve Thompson
On 02/25/2016 01:39 AM, Peter Hunkeler wrote:
Nevertheless, absolute 0 is owned by PR/SM, right?
The 8 KiB area at absolute 0 is the place where the hardware writes status information as
result of performing the "Store Status" operation. It has existed for longer
than PR/SM. I would say, it is owned by the hardware.
There is Absolute addressing, real addressing, and virtual addressing.
... and for practical purposes absolute and real addressing are the same,
except when takling about the 8 KiB at real address 0 and the 8KiB point to by
the prefix resigsters.
But wait a minute, isn't there on more level? Absolulte, real, and virtual are *within*
an LPAR. It is required to support multi-CP operating system *instances*. Since PR/SM,
each LPAR must have its own "absolute address 0", doesn't it? Actually, the
requirement has exited since physically partitionable CECs had been in place (can't
remember exaxtly which were the first such machines, 3033, or 308x, or?).
The net would be: Some code is accessing virtual address 0. The DAT feature will (with the help of
the DAT tables) translate virtual 0 to *a* real address (which just happens to always be real
frame 0 in z/OS). The hardware will recognize an address within the "prefixing area" (8
KiB in z/Architcture, 4 KiB in ESA/390 and predecessors, 2 KiB in even earlier architectures?), and
will translate real 0 (with the help of the Prefix Register) to absolute 0 (for this LPAR). Some
other part of the hardware needs to translate "absolute 0 of this LPAR" to a *physical*
memory address (how this works in detail is far beyond my knowledge).
--
Peter Hunkeler
<snippage>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
