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

[Dan Cross]

In article <5d2fe9bd-f475-44df-89c7-93f61f27ee09n at googlegroups.com>,
gah4  <gah4 at u.washington.edu> wrote:
>On Monday, May 15, 2023 at 5:15:41 AM UTC-7, Dan Cross wrote:
>> In article <8b6c6dbd-5dc4-41aa... at googlegroups.com>, 
>> gah4 <ga... at u.washington.edu> wrote: 
>> >[snip]
>> >In the case of virtual machines, each one will have its own CPU timer, 
>> >but only one TOD clock. STCK is not a privileged instruction, so programs 
>> >(or OS) see the host clock.
>
>> This would seem to violate Popek and Goldberg's virtualization 
>> criteria; how is that squared? 
> 
>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.

This _can_ be pretty easily papered over by using a hardware
technique similar to VMX (which gives the VMM a fair amount of
capability to virtualize the TSC, for example), but I don't know
whether they do that or not.  It stands to reason that they may.

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.

>It might have changed later, as not much pre ESA/390 hardware was still
>running by Y2K.  The favorite IBM method when a feature changes, is to put
>in a control register bit that allows the new or old operation.
>
>Wondering about some of those, I found this one:
>
>https://www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf
>
>which is the VMware description of how they virtualize clocks.

This describes most of the PC time sources, and how they are
virtualized in VMWare ESXi, but omits the important technique of
supporting enlightenments.  To be clear, a hypervisor can
provide sufficiently robust implementations of most PC time
sources that an unmodified guest won't really be able to tell
the difference between the virtualized and host environments,
but at the cost of non-trivial complexity and cost (particularly
when one starts to consider, e.g., migration of VMs between
physical hosts, as is common in cloud environments).  Thus, this
is one area where it is advantageous to paravirtualize; if the
OS can detect that it is running in a virtualized enviornment,
it can coordinate with the host to provide e.g., more robust and
accurate timing services.  This is supported by Hyper-V, KVM,
Bhyve, and a few other x86 hypervisors; it wouldn't surprise me
if similar techniques were employed on the mainframe as well.

Incidentally, I believe that Microsoft coined the term
"enlightenment" with Hyper-V.

	- Dan C.