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

Anthony Liguori
2010-12-14T15:32:27Z

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