[vbox-dev] Internal design question

Tue Mar 31 11:13:06 GMT 2009

Knut St. Osmundsen wrote:
> Hi Jonas,
>
> my apologies for the late answer (too busy with the upcoming release).
>   
You're excused since you are working on important issues 8-) I browsed
the answer and I will get back to you (& the list) if there is anything
I am curious about. You're answer is within what I expected, but I have
to read it more carefully to fully grasp the impact. Anyway, thanks for
the very descriptive and detailed answer.

/Jonas
> Jonas Mellin wrote:
>   
>> I am running Windows XP as host and Ubuntu 8.10 with Linux 2.6.24.7-rt27
>> (real-time preemption) as guest. I wonder how the high precision timer
>> is affected by the use of virtualbox in this setup. I can perceive a few
>> scenarios myself:
>> 1) The timer runs without interference of the virtualization. The only
>> effect is that the host affects the guest by delaying its execution.
>> 2) In the switch between host and guest, the value of the timer is saved
>> and restored. The effect is that in terms of execution time, there is no
>> delays due to the host system. However, w.r.t. absolute time there is a
>> devation that goes undetected unless the system clock is accessed.
>> 3) The timer does not work. My test programs gives the impression that
>> it works, so I have discared this scenario.
>>
>>     
>
> Scenario 1 is pretty close to what happens I'd say.
>
> Let me give you a quick rundown of how it all works w.r.t. timers and time.
>
> Time sources are, with the exception of the time stamp counter (TSC),
> associated with devices. Some of the devices provide timer service, like
> raising interrupts when a counter reaches zero. Most of them expose time
> in some way or another and can be used by the guest for time keeping. In
> order to keep all the important time sources in sync (so that they show
> the "same" time) they are all running on the same clock internally in
> the virtual machine monitor (VMM). So, for instance the TSC is a
> function of the CPU frequency and the delta since it started counting.
> Similarly, the programmable interrupt timer (PIT) finds the current
> counter value by the delta since it was started, predefined PIT
> frequency and the period length. The PIT also schedules a timer with the
> VMM for raising an interrupt when the counter reaches zero.
>
> The VMM timers are executed as soon as we see them expire. But this
> means we're subject to several sources of delay:
>   1. Host OS scheduling of the VMM threads,
>   2. Being too busy executing guest code that we don't notice the
>      expired timer, and
>   3. Dispatching and executing the interrupt handler of the guest.
>
> The 1st point is unavoidable since we're not in control over the OS.
> We're sharing the CPU resources with the rest of the system and we're
> subject to scheduling.
>
> The 2nd point is being addressed by upcoming hardware where it will be /
> is possible to program VT-x/AMD-V to stop execution of guest code after
> a given time. But for the time being, if a guest executes CPU intensive
> code that doesn't touch any of the time sources and doesn't cause any
> other virtualization exits/traps, we won't get a chance to check for
> expired timers until a host interrupt occurs.
>
> The 3rd point is related to the 1st one. It might take a little while
> before we manage to dispatch the interrupt to the guest's interrupt gate
> and execute it. Partly because we have to do a little bit more work that
> real hardware does when it receives an interrupt, and also because we
> can be preempted while doing this.
>
> The first two points will result in delays in the execution of the VMM
> timers, which in turn will propagate down to the PIT interrupt for
> instance. We cope with this problem by gradually speeding up the clock
> as we're lagging behind. The lag is measured by how late we're executing
> the VMM timers for the typical timer and time source devices (PIT, RTC,
> ACPI, APIC, HPET and TSC). In order to provide the guest with a
> consistent set of time source, the previously mentioned device will use
> a special clock which pauses when there are expired timers waiting to be
> executed and is speed up to catch up the lost time. (The alternative
> would be to use a clock which keeps on moving when for instance the PIT
> interrupt timer expires. This would for instance result in that the PIT
> counter will not necessary be zero when the interrupt is raise and upset
> the guest. Or in completely incorrect results when the guest pits the
> TSC against the RTC or PIT to measure the CPU frequency or TSC reliability.)
>
> The speed up currently starts at 5% and slowly increases to 500% as we
> lag more behind. Since there is no guarantee that we will be able to
> catch up (CPU is over committed and other factors), we will give up
> after 60 seconds (that's 60 seconds monotonic host time). Note that
> these parameters are all subject to change (tuning).
>
> Back to your scenario, high precision timers in a RT linux guest running
> on Windows XP. From the guest point of view, the timers will be running
> almost as expected. From the atomic wall clock point of view, the high
> precision guest timers will frequently be delivered as expected, but
> sometimes a longer interval occurs and it is followed by a series of
> shorter ones. From the VMM point of view, it's an best effort kind of
> thing. :-)
>
> Hope this was of some help to you.
>
>   


-- 
Carpe Diem!
===
Jonas Mellin, Assistant Professor in Computer Science
School of Humanities and Informatics, Building E-2
University of Skövde, P.O. Box 408, SE-541 28 Skövde, Sweden
Phone: +46 500 448321, Fax: +46 500 448399
PGP Public Key: http://www.his.se/PageFiles/19377/Jonas_Mellin.asc
Email: jonas.mellin at his.se, URL: http://www.his.se/melj, 

----BEGIN GEEK CODE BLOCK----
GCS d s a+ C++ UL++ US++ P++ L++ E++ W++ N+ o K- w++ O- M V-- 
PS- PE+ Y+ PGP t+ 5 X R* tv- b++ DI+ D+ G+ y++++ e++++ h--- r+++
----END GEEK CODE BLOCK----


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20090331/1a7c8d54/attachment.sig>