Re: [RFC 0/4] KVM in-kernel PM Timer implementation

Ulrich Obergfell
2010-12-14T14:44:52Z

----- "Avi Kivity" <avi@redhat.com> wrote:

> On 12/14/2010 03:40 PM, Glauber Costa wrote:
> > >
> > > What is the motivation for this? Are there any important guests that
> > > use the pmtimer?
> > Avi,
> >
> > All older RHEL and Windows, for example, would benefit for this.
>
> They only benefit from it because we don't provide HPET. If we did, the
> guests would use HPET in preference to pmtimer, since HPET is so much
> better than pmtimer (yet still sucks in an absolute sense).
>
> > > If anything I'd expect hpet or the Microsoft synthetic timers to be a
> > > lot more important.
> >
> > True. But also a lot more work.
> > Implementing just the pm timer counter - not the whole of it - in
> > kernel, gives us a lot of gain with not very much effort. Patch is
> > pretty simple, as you can see, and most of it is even code to turn it
> > on/off, etc.
> >
>
> Partial emulation is not something I like since it causes a fuzzy
> kernel/user boundary. In this case, transitioning to userspace when
> interrupts are enabled doesn't look so hot. Are you sure all guests
> that benefit from this don't enable the pmtimer interrupt? What about
> the transition? Will we have a time discontinuity when that happens?

Avi,

the idea is to use the '-kvm-pmtmr' option (in code part 4) only
with guests that do not enable the 'timer carry interrupt'. Guests
that need to enable the 'timer carry interrupt' should rather use
the PM Timer emulation in qemu userspace (i.e. they should not be
started with this option). If a guest is accidentally started with
this option, the in-kernel PM Timer (in code part 1) detects if
the guest attempts to enable the 'timer carry interrupt' and falls
back to PM Timer emulation in qemu userspace (in-kernel PM Timer
disables itself automatically). So, this is not a combination of
in-kernel PM Timer register emulation and qemu userspace PM Timer
interrupt emulation.

Regards,

Uli