On Wednesday, May 17, 2023 at 10:49:26 PM UTC-7, terry-...@glaver.org wrote:
> On Wednesday, May 17, 2023 at 6:49:24 PM UTC-4, gah4 wrote:
> > The design is that there is a button on the operators panel that you
> > press to allow changes.

> It is a momentary toggle labeled "TOD CLOCK". The up position is labeled
> "SECURE" and the down position is labeled "ENABLE SET".
> The OS would prompt you to toggle the switch during boot (IPL).
> At least on the 370/138, it is conveniently located next to the power off button...

It is less well described in the Principles of Operation, but pretty close.

But okay, a little tape and then the system can change it anytime.

On Wednesday, May 17, 2023 at 5:25:40 PM UTC-7, Arne Vajhøj wrote:

(snip)

> A hypervisor is not a host OS.
> Not in terminology and not in functionality.
If MS-DOS is an OS, even though it doesn't do most things that OSs should do,
a hypervisor doesn't seem so far off.

And if you consider the way CMS runs under VM, then VM is even more OS-like..
VM does login/logout, disk space allocation, spooling, accounting, and probably
a few other OS things that I forgot.

And with a little work, you can run programs directly, without CMS in between,
not so much different than the way MS-DOS runs programs.

In article <fc3cc630-17f9-4ade-85f2-03a4ef87f6b9n@googlegroups.com>,
gah4 <gah4@u.washington.edu> wrote:
>On Wednesday, May 17, 2023 at 6:37:32 AM UTC-7, Dan Cross wrote:
>> In article <5d2fe9bd-f475-44df...@googlegroups.com>,
>
>(snip, I wrote)
>
>> >IBM was either lucky or smart, in the design of S/370, except for that one.
>
>> >As well as I know, it mostly wasn't a problem until Y2K testing. Who would
>> >want a machine with the clock wrong on purpose?
>
>> Who can say? Timezones have been a thing since railroads began
>> popping up. But I agree: it may have been considered totally
>> innocuous. Still, I find it odd that it wasn't considered for
>> virtualization particularly given that VM started life on S/360.
>> Then again, S/370 was 1970, and Popek and Goldberg didn't
>> publish until 1974.
>
>OS/360, which in later versions has support for S/370 hardware,
>uses a different epoch. But other than that, there is a standard
>epoch, and you are supposed to add/subtract for time zones.
>
>The usual epoch is midnight, Jan 1, 1900, I believe GMT.
>(UTC wasn't invented in 1900.) Using that one, the high order bit
>is always 1, as no were built before 1971. That is supposed to be
>the test for the usual epoch.
>
>Note that it overflows in 2042.
>
>(snip)

I don't know what this has to do with epochs; I was referring to
the date of introduction for S/370, which was sometime in 1970,
as I understand it. The point was that Popek and Goldberg
published several years after S/370 was introduced, so it's not
terribly surprising that S/370 would not completely conform to
the P&G virtualization criteria.

>> It strikes me that setting the clock must be a privileged
>> operation, and it wouldn't take much for the hypervisor to save
>> and restore the clock on switches between VCPUs (and of course
>> it would have its own offsets for maintaining time in each VM
>> relative to the host). In that case, allowing unfettered reads
>> wouldn't be too much of an issue. Perhaps that is what they do.
>
>The design is that there is a button on the operators panel that you
>press to allow changes. But worse, there is no way to change it,
>and keep the previous value. (Funny, as IBM is pretty good at doing
>that everywhere else.) If you disable interrupts, you can minimize
>the counts lost. But you have to ask the operator to press the button.

Of course, in a virtual machine, that button, too, is virtual,
and asking the operator to depress it really means asking the
hypervisor to behave as if it had been pressed. Assuming it
requires a privileged access to do the actual write, this can
be intercepted by the hypervisor and cached; when the hypervisor
context switches to a different VCPU for a different virtual
machine, it simply squirrels the value away and replaces it in
the actual hardware register with the value associated with the
new VM. When it switches back, it does the same thing in
reverse. Effectively, the register is banked inside of the VMM,
just like a general-purpose register.

>The OS/360 interval timer, described above, is designed so one can
>read the value at the same time (one instruction) as setting a new value.
>No ticks are lost. (Careful use of the MVC instruction.)

Okay.

- Dan C.

In article <0968d262-1b9c-46b9-b138-54387b83dafan@googlegroups.com>,
gah4 <gah4@u.washington.edu> wrote:
>On Wednesday, May 17, 2023 at 5:25:40 PM UTC-7, Arne Vajhøj wrote:
>
>(snip)
>
>> A hypervisor is not a host OS.
>
>> Not in terminology and not in functionality.
>
>If MS-DOS is an OS, even though it doesn't do most things that OSs should do,
>a hypervisor doesn't seem so far off.
>
>And if you consider the way CMS runs under VM, then VM is even more OS-like.
>VM does login/logout, disk space allocation, spooling, accounting, and probably
>a few other OS things that I forgot.
>
>And with a little work, you can run programs directly, without CMS in between,
>not so much different than the way MS-DOS runs programs.

Just so.

I like Mothy Roscoe's definition of an operating system:

"The operating system is that body of software that:
- Multiplexes the machine's hardware resources,
- Abstracts the hardware platform,
- Protects software principals from each other,
(using the hardware)"
(https://www.usenix.org/conference/osdi21/presentation/fri-keynote)

If one considers "software principles" to mean the guest
operating system, and "abstracts the hardware platform" to mean,
say, provision of device models to the guest, then hypervisors
(even those of the so-called "Type-1" variety) meet this
definition. Indeed, a type-1 HV may match this definition
even more closely, since it must provide some abstraction
whereby some _other_ software component can provide services to
guests _and_ direct control of the VMM itself vis, say,
scheduling and allocation policies; usually this is in the form
of a sepecially blessed VM (Hyper-V calls this the "root VM",
while Xen calls it "Dom0"), but that needn't be the case.
Importantly, Type-1 hypervisors also drive the host hardare in a
way that no other software component _can_.

This is why people who actually build hypervisors see the
distinction between "Type-1" and "Type-2" as more of an
convenient abstraction than a concrete difference. For example
_technically_ Hyper-V is a type-1 hypervisor, even though in
practice it's completely inseparable from Windows; similarly,
KVM is often billed as a Type-1 HV but is intimately tied to the
OS it runs alongside with. In contrast, z/VM provides many
services typically associated with a host OS and IBM calls it a
type-2 hypervisor, even though it runs directly on the bare
hardware.

- Dan C.

In article <u43ra1$13to$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 5/15/2023 4:47 PM, Dan Cross wrote:
>> In article <u3tv4e$34ma3$1@dont-email.me>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> The hypervisor is there.
>>>
>>> But no host OS.
>>
>> For all intents and purposes, the hypervisor _is_ the host OS.
>> Some software component must drive the hardware, run VCPUs, etc:
>> that's the hypervisor.
>
>A hypervisor is not a host OS.

This is an odd thing to say; see my other response in this
thread, but a "Type-1" hypervisor very much meets most
reasonable definitions of an "operating system." For example,
taking Roscoe's definition that I mentioned earlier:

"The operating system is that body of software that:
- Multiplexes the machine's hardware resources,
- Abstracts the hardware platform,
- Protects software principals from each other,
(using the hardware)"
(https://www.usenix.org/conference/osdi21/presentation/fri-keynote)

A hypervisor certainly qualifies based on these criteria, as I
again mentioned elsewhere in this thread. I will agree that
this is not a _general purpose_ operating system, but to assert
that it is not an operating system is simply incorrect.

>Not in terminology and not in functionality.
>
>The stacks are:
>
>guest OS
>type 1 hypervisor
>hardware
>
>and:
>
>guest OS
>type 2 hypervisor
>host OS
>hardware

This is a overly simplistic take, and not reflective of actual
implementation or practice.

Every extact "type-2" hypervisor in common use today has a
significant kernel-resident component that runs _as part of_ the
host OS; indeed, entry to a VM using both VMX and SVM on x86
requires execution of privileged instructions, and exit from the
VM context is always in ring0.

Consider Bhyve, for example: it is firmly in the "type-2" camp,
yet has a substantial kernel-resident VMM component that goes as
far as implementing several non-trivial device models (the PIC,
PIT, etc). This all runs "on the bare hardware."

>Host OS and hypervisors are terms used for different things.
>
>And used for things that provide different functionality:
>
>a host OS is a normal OS like Linux or Windows able to run
>applications in general including but certainly not limited
>to type 2 hypervisors

You seem to be conflating the idea of the operating system as
the body of software that drives the hardware and mediates
access to resources while providing abstractions for software,
with a general purpose operating system such as VMS or Unix.

>a type 1 hypervisor like VMWare ESXi is a special piece of
>software able to run VM's and partition the hardware resources
>between the VM's - usually they are extremely thin and with only
>this very specialized functionality - any heavy stuff
>are usually put elsewhere in a VM (often known as a Dom0
>VM) or a remote management application

You seem to be repeating things I've already said in this thread
regarding the root VM/remote control plane. For example, I said
more or less exactly this on May 15:
https://groups.google.com/g/comp.os.vms/c/nPYz56qulqg/m/Es3OgP_PCAAJ

Regardless, your characterization of e.g. ESXi is simply wrong.
Engineers I personally know who either have or do work in that
codebase acknowledge that it is a rather complex operating
system in its own right. Or consider Xen, which is another
type-1 hypervisor: we can actually examine its code, as it is
open source; it's hardly what you are describing it as.

>a type 2 hypervisor like VMWare Player is an application running
>on a host OS that runs a VM

This is only partially correct. In order to drive the
virtualization extensions provided by the hardware, these
applications _must_ have a kernel component: that is how the
hardware works.

>> The arbitrary distinction between "Type-1" and "Type-2" style
>> hypervisors is also a bit illusory among those who work on them;
>> like all approximations, it is just that.
>
>Anyone that works with them will know the difference between type
>1 and type 2 (and the difference between a hypervisor and a host OS).

Let's go back to Goldberg's original definitions from his 1972
dissertation, where the terms were introduced:

From https://apps.dtic.mil/sti/citations/AD0772809:
| Type I vs Type II VMM
| | The implementation requirement specifies that most VCS
| instructions execute directly on the host. It does not
| indicate how the VMM gains control for that subset of
| instructions that must be interpreted. This may be done
| either by a program running on the bare host machine or a
| program running under some operating system on the host
| machine. In the case of running under an operating system,
| the host operating system primitives may be used to
| simplify writing the virtual machine monitor. Thus, two
| additional VCS categories arise:
| | Type I--The VMM runs on a bare machine.
| Type II--The VMM runs under on an extended host, under
| the host operating system.
| | In either case, the virtual machine being created is
| equivalent to the bare host or a related family member.
| | Type I (bare host) and Type II (extended host) VCS's are
| illustrated in figure 2-4. In both Type I and Type II VCS,
| the VMM crates the VCS environment. However, in a Type I
| VCS, the VMM on a bare machine must perform the system's
| scheduling and (real) resource allocation. Thus, the Type I
| VMM may include much code not specifically needed for a VCS.
| In a Type II VCS, the resource allocation and environment
| creation functions are more clearly split. The operating
| system does the normal system resource allocation and
| provides a standard extended machine environment. The VMM
| program runs on the extended machine environment and produces
| a pseudo-hardware environment.
(Note: VCS here is "Virtual Computer System")

Now, in particular, Bugnion, Nieh and Tsafir noted that these
definitons are primarily concerned with resource allocation, and
that Goldberg assumed both types would execute with full
supervisor privileges over the machine. (Edouard Bugnion,
Jason Nieh, and Dan Tsafir: "Hardware and Software Support for
Virtualization". 2017; Morgan and Claypool.)

But note specifically where Goldberg says that a type-1
hypervisor must take on many of the functions of a traditional
operating system with respect to scheduling and resource
management; or as he put it: "Thus, the Type I VMM may include
*much code not specifically needed for a VCS*." Indeed, nothing
here suggests that a "Type-1" hypervisor cannot provide, say, a
filesystem for the division of storage resources between VMs.

For those who work on the implementation of these systems, we
must ask ourselves, what do these distinctions actually _mean_?
KVM bills itself as turning Linux into a type-1 hypervisor, and
it obviously makes heavy use existing kernel primitives (VCPUs
are associated with tasks, for example), yet it is entirely
kernel resident (interactions with KVM are via ioctls).
Similarly, the engineers working on ESXi acknowledge that it is
actually an operating system under the hood, with complex
interactions with storage devices, networks, a management plane,
etc. Then we get to things like Dune or gVisor, which are much
closer in spirit to what Goldberg described as a "type-2"
hypervisor, where they make use of the virtualization hardware
and provide an OS abstraction to an application.
https://web.stanford.edu/group/mast/cgi-bin/drupal/content/dune-safe-user-level-access-privileged-cpu-features
https://gvisor.dev/

Contextually, Goldberg was writing in an environment where
computers were physically large and expensive; the distinction
he wanted to make was whether the machine would be
simultaneously serving users running jobs along with VMs on the
same host, of users would be interacting only with VMs. In that
context, what does it mean in the modern era where a machine in
a rack in a datacenter _may_ be running a "type-2" hypervisor
but never run anything other than VMs and a thin management
plane? This would de-facto meet Goldberg's type-1 criteria,
despite the archtecture of the overall system. And Goldberg
himself acknowledged that a type-1 hypervisor would necessarily
take on many of the functions of a host OS. So no, these lines
are a lot blearier than the naive interpretation.

>It is not an approximation. It is distinct as the difference
>between 3 and 4.

Nope.

At the end of the day, modern hypervisors do not fit into neat
little categories defined in 1972, either in implementation or
practice.

- Dan C.

On Monday, May 8, 2023 at 1:06:34 PM UTC-4, John Dallman wrote:
> In article <kbsanj...@mid.individual.net>, bill.gu...@gmail.com
> (bill) wrote:
>
> > Because we often hear that there are still people running Vaxen
> > with VMS on them and I expect moving a program from the VAX to
> > x86-64 would be difficult if not impossible (especially if it
> > has any MACRO in it!)
> If you have the source, the MACRO cross-compiler to x86 is available. It
> had to be: chunks of VMS are still written in it.
>
> John
John,

A note of caution from past experience: MACRO-32 that ran on VAX processors may need a bit of work before it will compile on Alpha/Itanium/x86-64 processors. Been there; done that. Some old VAX code is particularly crufty, e..g., full of PDP-11 like coding shortcuts that do not map well onto later processors. The parts of the OpenVMS base that are in MACRO-32 have now undergone three different wash cycles to remove problematic code.

That is not to say that it cannot be done, merely that a full audit of the code is required before undertaking the effort. Code already being compiled for Alpha/Itanium is a different story. Given the present tools situation, I would probably opt to do the initial version on an Alpha/Itanium host, moving to x86-64 after the kinks have been excised.

- Bob Gezelter, http://www.rlgsc.com