[Info-vax] clock problems with OpenVMS x86 on VirtualBox

[Dan Cross]

In article <fc3cc630-17f9-4ade-85f2-03a4ef87f6b9n at googlegroups.com>,
gah4  <gah4 at u.washington.edu> wrote:
>On Wednesday, May 17, 2023 at 6:37:32 AM UTC-7, Dan Cross wrote:
>> In article <5d2fe9bd-f475-44df... at 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.