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

[Avi Kivity <avi@redhat.com>]

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