|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] [PATCH]HVM acpi timer update
Christian,
Using vm_clock counter delta to calculate acpi timer is an ideal
solution provided os only accessing acpi timer port using polling mode.
Currently acpi implementation using acpi only event model without power
manager support. Guest OS only do acpi timer polling. At the time when
we need to add hvm guest device acpi power manager support, acpi timer
will be not only being used as platform profiling in polling mode but
also need to severe to generate SCI when timer expired.
I was changing the qemu_mod_timer fire at time interval of 1.15ms for
acpi windows boot, but windows installation is failed, so have to set
that timer invocation at 0.027ms. And testing showing both have the
equivalent performance for kernel build and IDE DMA as non acpi mode.
We don't have power management support now. So we can implement a
vm-counter based acpi timer support OS polling mode and leave acpi power
management support as a separate effort.
Regards,
Winston,
Christian Limpach wrote:
> On 7/27/06, Wang, Winston L <winston.l.wang@xxxxxxxxx> wrote:
>> The patch updated the hvm acpi timer by reducing invocations to
>> timer_update and some minor code style clean up:
>> 1) Fixed new qemu 0.8.1 pm timer incorrect frequency and allow acpi
>> windows install and boot correctly
>> 2) Resolved performance issues caused by old acpi timer, testing
>> showing guest IDE DMA and kernel build have the same performance on
>> non-acpi mode.
>
> Why does this still need a timer at all? Why can't we just compute
> the acpi timer's value when it is being read: (get_vm_clock() -
> vm_clock_value_when_domain_was_started) divided/multiplied to get the
> expected frequency?
>
> Also, since this is using vm_clock, the acpi_timer will advance even
> if the domain is not scheduled -- is this the expected behaviour?
>
> christian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|