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

[Arne Vajhøj]

On 5/15/2023 9:45 AM, Arne Vajhøj wrote:
> On 5/15/2023 8:53 AM, Johnny Billquist wrote:
>> On 2023-05-15 14:36, Arne Vajhøj wrote:
>>> 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.
>>
>> Can you guarantee that no interrupts happens on the CPUs the 
>> hypervisor is using? I would suspect "no", which means you do not have 
>> full control.
> 
> What would those interrupts do?
> 
> A type 1 hypervisor does not do that much.
> 
> It has not very much in common with a type 2 hypervisor. I see it
> as more of a software equivalent of system partitioning (DEC Galaxy,
> IBM LPAR).

As I don't know much about hypervisors and real time, then
no need to take my opinion too serious.

But one can look at the market.

VMWare officially talks about real-time:

https://docs.vmware.com/en/VMware-Edge-Compute-Stack/1.0/ecs-enterprise-edge-ref-arch/GUID-99972F62-3FAE-42B2-A850-66402274B616.html

And a whole bunch of special type 1 hypervisors for real time usage exist:

Wind River Helix - 
https://www.windriver.com/solutions/learning/hypervisor and 
https://www.windriver.com/products/helix

RTS - https://www.real-time-systems.com/

Acontis - https://www.acontis.com/en/acontis-hypervisor.html

Some people besides me seems to think that VM and real time is possible.

Arne