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

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/14/2010 07:49 AM, Avi Kivity 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?
>
> What I'd really like to see is this stuff implemented in bytecode, 
> unfortunately that's a lot of work which will be very hard to upstream.

Fortunately, we have a very good bytecode interpreter that's accelerated 
in the kernel called KVM ;-)

Why not have the equivalent of a paravirtual SMM mode where we can 
reflect IO exits back to the guest in a well defined way?  It could then 
implement PM timer in terms of HPET or something like that.

We already have a virtual address space that works for most guests 
thanks to the TPR optimization.

Regards,

Anthony Liguori