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

[Arne Vajhøj]

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:
>>> On 2023-05-15 14:03, Arne Vajhøj wrote:
>>>> On 5/15/2023 6:17 AM, Johnny Billquist wrote:
>>>>> On 2023-05-13 02:16, Arne Vajhøj 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?
>>>>>
>>>>> For sure. You have no guarantee that you will get the CPU cycles 
>>>>> when you need them. No matter what kind of hypervisor we're talking 
>>>>> about, there is overhead in the host that can affect things way 
>>>>> more than what might happen on bare metal.
>>>>
>>>> What host? A type 1 hypervisor does not run a host OS.
>>>
>>> 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.

>               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.

>                                   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?

>>>> And why would the CPU not be available, when there is no
>>>> over allocation of resources? It seems pretty silly of
>>>> the hypervisor to not want to give the CPU if no other
>>>> VM can get it.
>>>
>>> Any kind of hypervisor means we're talking about virtualization. That 
>>> means you have real hardware which exists outside of this 
>>> virtualization. And that hardware can generate interrupts and demand 
>>> service, which then forces the hypervisor to wait before it can 
>>> actually get any cycles. Outside the control of the hypervisor...
>>
>> Maybe. But what would that be?
> 
> 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.

Only shared L3 cache can give some uncertainty.

And we are in ns space not us space here.

Arne