Re: [patch 01/12] expose ACPI pmtimer to userspace (/dev/pmtimer)

[Marcelo Tosatti <mtosatti@redhat.com>]

On Mon, Jun 02, 2008 at 09:43:20AM -0700, John Stultz wrote:
> > 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.

In that case (host resume from S-state) we can hold guest execution
until the real hw timer is in proximity to the guests expectation, or
fallback to emulation (but its not unsolvable).

This problem can happen now with the TSC since kvm's suspend routine
isnt saving it.

Thanks for the reminder.

> > > > 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).

Good point. Will go for the acpi_pm's private sysfs file.