Ramon:
The basic answer is:
don't worry about it
Consider DOS.
A job gets the CPU, the whole CPU, except for some hardware
generated interrupts, which are also under the programs
control.
If we are emulating/virtualizing, the VM gets the CPU for
as long as it runs. It will stop running on (1) a hardware
interrupt, or (2) loss of quantum. If its a hardware interrupt,
it may be (hopefully quickly) vectored back into the VM for
final disposition. The only problem is when other tasks are
running.
Now, a DOS program really has no idea of time (most of these
were written before the advent of RDTSC!). The only concept
of time that the program has are (1) the status of the RTC
-- which is ok, (2) the BIOS tick timer in memory -- which may be ok,
and (3) the system clock interrupt, which isn't ok.
The problem is the delivery of the system clock interrupt
(off the top of my head 14.2 per second), or, if its been
reprogrammed, some other rate.
Some DOS applications assume that the system clock CANNOT
be re-entrant because the interrupt processing will be
finished well within 1/14 of a second. These apps will
give problems. The general fix is to simply time the
amount of time that we are "away", and deliver extra
clock tick interrupts to the running VM, with a re-entrancy
hold-off (how do you know this? a nasty little question,
and I don't have a good solution, but see the next section.).
Now, if the program attempts to time instruction execution,
it will have to look at an external time base, and then
execute. What saves us is that the time base can be caught.
[Pull a scheduling window over the next piece of code, giving
the program virtually 100% of CPU for the next second or so.
This covers most uses of RDTSC and other time-base checks,
such as the "Zen timer"]. I also propose that allowing
for execution windows and interrupt throttling can help
with interrupt re-entrance issues as well.
You will never be 100% accurate, but it can be "good enough".
If the system is SO loaded that the clock can't keep up
(that is, timer tick interrupts cannot be delivered and must
be discarded), then the user can be warned. Unfortunately,
there is NOTHING that plex86 can do about this. As an example,
consider playing DOS DOOM in plex86 while another task is
doing video surveillance. The DOS task is of lower priority,
but the VM doesn't know this (rather vital) information.
It SHOULDN'T boost priority any more other than to be able
run VMs effectively.
As to multimedia... the same rules apply. An external time base
must be referenced. We can deliver clock interrupts at the
appropriate times, with extra being delivered if need be.
If the machine isn't loaded, the multimedia stuff will work
properly. If the machine IS loaded, we can't predict what
the correct behaviour should be. The operator must assign
priority to indicate what should happen. Again, it isn't
the VM's responsibility to figure this out.
----Original Message Follows----
From: Ramon van Handel <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: plex86: progress...
Date: Tue, 04 Jul 2000 00:29:40 +0200
MIME-Version: 1.0
Received: from [212.204.201.31] by hotmail.com (3.2) with ESMTP id
MHotMailBB2A5E4B00A1D820F3B6D4CCC91F055E0; Mon Jul 03 15:27:27 2000
Received: by lightning.fastxs.net (Postfix)id C9ACDE8069; Tue, 4 Jul 2000
00:27:15 +0200 (CEST)
Received: by lightning.fastxs.net (Postfix, from userid 522)id 8A8FEE8048;
Tue, 4 Jul 2000 00:27:15 +0200 (CEST)
Received: from unit11.support.nl (unit11.support.nl [195.114.229.252])by
lightning.fastxs.net (Postfix) with ESMTP id 892EAE8048for
<[EMAIL PROTECTED]>; Tue, 4 Jul 2000 00:27:14 +0200 (CEST)
Received: from chem.vu.nl (noterik.support.nl [195.114.229.16])by
unit11.support.nl (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id AAA31735for
<[EMAIL PROTECTED]>; Tue, 4 Jul 2000 00:28:23 +0200
>From [EMAIL PROTECTED] Mon Jul 03 15:27:33 2000
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Authentication-Warning: unit11.support.nl: Host noterik.support.nl
[195.114.229.16] claimed to be chem.vu.nl
Message-ID: <[EMAIL PROTECTED]>
Organization: Chemisty Department, Vrije Universiteit, Amsterdam, The
Netherlands
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.3-5 i586)
References: <v01550105b5865ec4daa9@[130.37.144.207]>
<[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
Precedence: bulk
Kevin Lawton wrote:
> Keep in mind that the TSC is a host time based reference. We sample
> this to compute the duration of a segment of guest execution. As
> you mention, we can skew the clock in the monitor between segments
> of execution of the guest code. Now let's assume we need an event
> delivered in the middle of some guest code. Whether or not the
> event is based simply on guest execution cycles, or skewed (compressed)
> timing, let's assume we know algebra and can figure out where to
> deliver it. Thus, the real issue is to find a way to interrupt
> us at that point.
Yes, I do understand this!! but it doesn't solve the problem, as
I see it (though it does reduce it). Let me try to explain
again.
Consider this: you can always skew your timing, but you can never
skew the amount of instructions the processor can execute in a
certain amount of time. Consider two quanta of the VM, which
(for whatever reason, load change or whatever) have different
skewing parameters (in the one the virtual clock goes faster
than in the other). That means, that X amount of BogoMIPS loops
will actually correspond to *different* virtual lengths of time !
The only way to avoid this (as I see it) is to somehow make
sure that the skewing parameters remain more or less constant
during the VM run.
> As far as running "real-time" software like video/audio players,
> the way to best take care of this is to emulate a real or (even
> better yet) a pseudo device, ship the data to the host side,
> buffer it, and play it on the host side. Seems like you could
> put in requested timeframe delimiters, so the host software
> knows where the time boundaries are, and can process the data
> according to these time references, based on real host time.
Of course this would be nice, but running old DOS software (for
instance) would still require pretty accurate timing... and you'd
like at least halfway decent performance even for guests that
you did not write custom drivers for (yet).
-- Ramon
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
