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. Signed-off-by: Winston Wang <winston.l.wang@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 7/27/06, Wang, Winston L <winston.l.wang@intel.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
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@intel.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
On 7/28/06, Wang, Winston L <winston.l.wang@intel.com> wrote:> 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.Ah I see, but even in that case, we should be able to setup a qemu timer to fire only once the pm1_timer will reach zero or whatever the condition for generating an SCI is. christian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yes, Don''t worry about SCI now since we don''t have support for hvm guest device power management for device idle timer, Thanks, Winston, Christian Limpach wrote:> On 7/28/06, Wang, Winston L <winston.l.wang@intel.com> wrote: >> 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. > > Ah I see, but even in that case, we should be able to setup a qemu > timer to fire only once the pm1_timer will reach zero or whatever the > condition for generating an SCI is. > > christian_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel