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

[Arne Vajhøj]

On 5/15/2023 8:20 AM, Simon Clubley wrote:
> On 2023-05-12, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 5/12/2023 1:30 PM, Simon Clubley wrote:
>>> On 2023-05-12, Dave Froble <davef at tsoft-inc.com> wrote:
>>>> On 5/12/2023 8:14 AM, Simon Clubley wrote:
>>>>> That's going to make for some "interesting" real-time program behaviour... :-)
>>>>
>>>> Do you think any serious real time programmer will run a real time task inside a
>>>> VM?  I'm not a real time programmer, and I'd still not do that.
>>>
>>> As well as traditional real-time stuff (which I agree with you about BTW),
>>
>> I would not want to do it on a type 2 hypervisor - there must be
>> cases where what is happening on the host OS impact the performance
>> of the guest OS.
>>
>> But with a type 1 hypervisor and no over allocation of resources -
>> would it be worse than running on bare metal?
> 
> A type 1 hypervisor is still a software layer between the hardware and
> the RTOS. It would have to _guarantee_ that it would _never_ get in the
> way of the timing guarantees that a program running under a RTOS needs.

It is software that is active between the VMS and the HW.

But it is not obvious to me where any delay would come from.

If we talk type 2 then it is easy to understand. You have a host
OS running 200 processes - 1 VM and 199 other stuff, and 4 CPU
so those 200 processes get scheduled on those 4 CPU's, and certain
interrupts may happen in the host OS. That VM will have
a problem providing real time capabilities.

But in the type 1 with no over allocation of resources then
what will cause any delays? The VM got its own CPU or CPU's
that no other VM want, so I would expect the hypervisor to
keep them permanently allocated to the VM. And I don't
see the need for any interrupts in the hypervisor either.

Arne