On Sun, Jun 01, 2008 at 06:34:27PM +0200, Thomas Gleixner wrote: > On Thu, 29 May 2008, Marcelo Tosatti wrote: > > KVM wishes to allow direct guest access to the ACPI pmtimer. In that > > case QEMU/KVM has to read the current value for migration, so the proper > > syncing can be done on the destination. > > I don't understand from the above which problem you are trying to > solve. Which pmtimer is read out, the one of the host (physical > hardware) or the one of the guest (emulated hardware) ? What is synced > at the destination ?
Problem is this: We want to allow guests to directly access the hosts pmtimer (by using the I/O bitmap feature in VMX/SVM hardware). The advantage of doing it is that no VMExits are necessary for guest pmtimer reads (which happen often if we inform the guest that ACPI C1 state is supported, or if the workload is gettimeofday() intensive). If you migrate such a guest that has direct (ie. non-virtualized, using the physical hardware) pmtimer access to a different host (destination), you need to save the current host pmtimer value at the time of migration so that you can either emulate it with a proper offset or synchronize (wait for the destination hosts real hardware pmtimer value to be in sync before actually resuming guest execution). > > This patch will not register the device if the chipset has an unreliable > > timer. > > Can we please keep that code inside of drivers/clocksource/acpi_pm.c > without creating a new disconnected file in drivers/char ? > > Btw, depending on the use case we might as well have a sysfs entry for that. A sysfs entry sounds fine and much simpler. Should probably be a generic clocksource interface (so userspace can read any available clocksource) rather than acpi_pm specific. <snip> > return clocksource_acpi_pm.read == acpi_pm_read; > > So we don't need reliable_pmtimer at all. For KVM's use case, we'd rather not allow direct pmtimer access if the host has an unreliable (buggy) chipset. But then, I doubt any of those older affected chipsets have HW virtualization support, so it shouldnt be an issue. Thanks! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
