Ramon van Handel wrote:
>
> Kevin Lawton wrote:
> >
> > Ramon van Handel wrote:
> >
> > > Uh, you mean the lapic timer ? Not that I can see..
> > > Not in a reliable way, anyway.
> >
> > Yeah the Local APIC timer. Humm, I'll have to read up
> > on it more. With timers in general, you can multiplex
> > them. Given you know when they're supposed to go off
> > next (according to the host OS view), we might be
> > able to take a time sampling, and store away the
> > current LAPIC timer settings. Then run the guest for a timeslice.
> > Once the timer hits, we'll be back in the
> > host kernel module to handle the interrupt redirection
> > and thus can take another sampling, and restore the LAPIC
> > timer back to some sensible value considering.
>
> > Since we know how long we were in the guest context due
> > to our time samplings with RDTSC, we can increment the
> > LAPIC timer based on this so it's accurate from the
> > host's perspective.
>
> Why can't we just do this with the PIT, then ?
> Doesn't sound extremely reliable to me, but for a timesharing
> host system it should do.
This could be our back-up plan for 486 machines and ones that
don't have RDTSC. We'd have to reprogram the PIT temporarily
and then put it back for the host. Not sure what the issues
are, but it sounds feasible.
-Kevin
