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

[Dan Cross]

In article <u3tv4e$34ma3$1 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 5/15/2023 1:47 PM, Johnny Billquist wrote:
>> On 2023-05-15 15:35, Arne Vajhøj wrote:
>>> On 5/15/2023 8:51 AM, Johnny Billquist wrote:
>>>> Um? What is the hypervisor then?
>>>
>>> The hypervisor software like ESXi.
>>>
>>> It is not running on top of a host OS like a type 2 (VirtualBox etc.) 
>>> does.
>> 
>> I never assumed you had a full OS. However, they Hypervisor is 
>> intercepting access to hardware, and is responsible for the actual 
>> interaction with the hardware, adding a layer between the guest OS and 
>> the hardware.
>
>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.

>>               Which means that the hypvervisor is in the end doing 
>> interrupt handling, for example. Which means that the CPU might be doing 
>> things that suspends the execution for the hypervisor outside the 
>> control of the hypervisor itself,
>
>If the HW interrupts the CPU assigned to the VM and that interrupt
>is not intended for the VM and it actually require some processing,
>then it will steal CPU time from the VM.
>
>But because the hypervisor does so little it is not obvious to
>me what that would be.

Where do you think the device models that are exposed to the
guest are implemented?

>>                                   and further more makes things like 
>> interrupts to the guest OS happen at some random later time, including 
>> clock interrupts, which are what affects things like real-time reponse 
>> times.
>
>Why would that happen at a random later time?
>
>If the hypervisor gets the interrupt wouldn't it pass
>it on to the guest OS ASAP instead of queuing it up?

See above.  Where do you think that the device models exposed to
a guest are implemented?  What do you think controls IO, or e.g.
PCIe configuration space?  What do you think emulates legacy IO
devices like (on the PC) the PS/2 keyboard controller, PIC, PIT,
HPET, RTC, UART, etc?

IO in hypervisors does not, in general, go directly to a device.

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.

>> Primarily I would be worried about interrupts, which introduce unknown 
>> amout of delay.
>> 
>> But yes, for things like memory, if it is fixed allocated to VM 
>> instances, and always available, then another potential source of delays 
>> are at least not there.
>> 
>> Depending on what the hypervisor does, you might still also have issues 
>> like page table caches, and normal memory caches, which will have rather 
>> different behaviors compared to plain hardware. Caches are a significant 
>> factor is performance these days.
>
>Yes.
>
>But if the cache is per core and the VM get assigned not only
>a specific number of cores but a specific set of cores, then
>it is still predictable.

Any VM exit, such as mandatory exits for handling e.g. the
`CPUID` instruction, will necessarily conflict with the guest
cache (since the L1 and L2 I and D caches are shared with the
guest).

	- Dan C.