On Sun, 2008-06-01 at 14:56 -0300, Marcelo Tosatti wrote: > 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)
I'm a little wary on this, another thing to catch here as well is host suspend-resume cycles that might reset the pmtimer. > > > 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. Again, I'd be hesitant to expose this stuff to userland since if the counters reset (such as in the suspend/resume case) the applications may not be aware. And if its a generic interface, we would then have to also export frequency and mask values. It just gets messy, so I'd avoid doing anything generic in exporting clocksources (since either userland wants specific hardware and is aware of all the known troubles it may have, or userland should use the existing kernel time interfaces). thanks -john -- 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
