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

[Marcelo Tosatti <mtosatti@redhat.com>]

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!