On 12/8/20, 5:42 PM, "Linux on 390 Port on behalf of Paul Gilmartin"
<LINUX-390@VM.MARIST.EDU on behalf of paulgboul...@aim.com> wrote:
> z/VM doesn't hide the hardware. In just about all cases, if it won't run
> in an LPAR, it also won't run under z/VM.
I recall a counterexample was OpenSolaris. It wouldn't run in
an LPAR, but only under VM. I suspect the matter was not "hid[ing]
the hardware" but required CP services not available from the hardware.
FWIW, with OpenSolaris, it was a deliberate decision on our part to require
z/VM, mostly because it made it easier/simpler/nicer to implement disk and
network device support -- it was a lot easier to let z/VM handle real cylinder
0 and allocate/treat minidisks as sequences of blocks with all the standard IBM
labels and info present (DIAG 250 allowed CMS formatted/reserved minidisks to
more easily map to traditional Unix I/O block devices, and we took advantage of
the caching infrastructure and system instrumentation already present in CP to
better integrate with the idea of running lots of production Solaris guests in
virtual machines) and to write network device drivers via DIAG 2A8 since IBM
didn't want to document the low-level hardware details of how OSAs worked at
that point in time.
With Solaris ZFS, the small size of traditional Z ECKD disks and the limitation
on minidisk size were irrelevant, and it played well with the hardware without
having to resort to special tricks to optimize around the Z I/O architecture.
All the available VM backup and performance tools already understood that
environs at the time, and we didn't need to invent separate tools to prepare
disk media or deal with Z-specific hardware problems.
Wrt the discussion at hand, IIRC, if you were in a z/Arch machine, it IPLed
directly into z/Arch mode, otherwise we had OpenSolaris initially IPL in ESA
mode and then programmatically upgrade to z/Architecture mode ASAP thereafter,
like the PoOps at the time said to do. We didn't worry about LPAR mode or bare
metal because a) we didn't want it, b) nobody else wanted it, and c) we're
VMers and already have a superior solution. __ It wouldn't have been able to do
disk or network I/O in its current form, but someone writing the necessary
device drivers would solve that problem.
Thinking about it, it probably wouldn't be a huge lift to make OpenSolaris run
on LPAR/bare metal now if we had to, but somebody would still have to convince
me why it's a good idea if z/VM is available.
It would be very interesting to see how it would behave in a modern SSI
environment - I think the approach we took would make it possible to migrate
it more easily than Linux.
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390
