Re: windows acpi time drift

[Avi Kivity <avi@qumranet.com>]

Dor Laor wrote:
> On Wed, 2008-03-19 at 17:39 +0200, Avi Kivity wrote:
>   
>> Anthony Liguori wrote:
>>     
>>> Avi Kivity wrote:
>>>       
>>>>   The fourth is probably impossible from userspace (and very 
>>>> difficult in the kernel).
>>>>         
>>> What makes it impossible to do in userspace?  If you managed a 
>>> tsc_offset in userspace, you would of course need to adjust that 
>>> tsc_offset within the kernel for the particular PCPU that you were on.
>>>
>>>       
>> In the kernel you can to tricks like local_irq_disable(); rdtsc(); 
>> ktime_get(); local_irq_enable() to get a sense where the tsc is.
>>     
>
> but you can also do it before the vcpu goes to userspace after vmexit.
>
>   

You only want to do it when needed.  We might add an ioctl for it, but 
it's tricky.

>> Take a look at kvm_inject_pit_timer_irqs() and 
>> kvm_pit_timer_intr_post().  An attempt to have a accurate userspace pit 
>> needs to take into account what those functions do.  I believe it's 
>> doable, but will require careful design of the interface (which should 
>> be usable for rtc and hpet as well).
>>
>>     
>
> Actually I'm coming to think we don't need a irq queue in the kernel.
> We just need to count the pending timer interrupts in userspace and
> change the qemu_set_irq interface to return a status when the irq was
> really injected by pic/apic (like kvm_pit_timer_intr_post).
>
> This way qemu timer devices will not inject another irq until the
> previous irq got ack by the kernel (or even userspace pic/acpi).
>   

Yes, I think you're right.  We can return the information in the vcpu 
shared area, so it doesn't generate new exits.


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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/