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

Avi Kivity
2010-12-14T15:38:12Z

On 12/14/2010 05:32 PM, Anthony Liguori wrote:
>>
>>> > 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 ;-)

We have exactly the same bytecode interpreter under a different name,
it's called userspace.

If you can afford to make the transition back to the guest for
emulation, you might as well transition to userspace.

>
> 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.

More exits.

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

It only works for Windows XP and Windows XP with the /3GB extension.

--
error compiling committee.c: too many arguments to function