> On 19 Jun 2015, at 18:24, Justin Cormack <[email protected]> wrote: > > On 19 June 2015 at 18:07, Anil Madhavapeddy <[email protected]> wrote: >> On 19 Jun 2015, at 17:50, Justin Cormack <[email protected]> >> wrote: >>> >>> On 19 June 2015 at 17:42, Martin Lucina <[email protected]> wrote: >>>> Also note that I have no idea what the stability of TSC is under KVM and >>>> the current code makes no attempt to figure out if TSC is invariant, >>>> constant, or anything else. So option 3) would also be a safe(r) bet in >>>> that the PIT should "just work". >>> >>> KVM has a PV clock, see summary of how it works here >>> https://rwmj.wordpress.com/tag/kvmclock/ >>> >>> Because clocks under virtualization are problematic, using this is >>> probably the best solution longer term. >> >> On Xen HVM, you can still use the PV hypercall to map the shared_info >> page and get the PV clock from there. Does all of that "just work" >> from the NetBSD Xen PCI bridge device driver and Rump/Xen? > > No one has looked at Xen/HVM yet as far as I know; upstream NetBSD > does not support PVHVM yet which would be one approach. Now Amazon > seem to be phasing out PV on favour of PV on HVM I guess this is > getting more urgent.
There's a difference between PVHVM (the new boot mode that always runs a PV guest inside an HVM container) and the older "enlightenment" mode, which attaches PV devices from within a vanilla HVM booting guest. There's some code that does this probing in NetBSD already: http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/cpuctl/arch/i386.c?rev=1.58.2.4 in cpu_probe_hv_features (see "XenVMMXenVMM") It should be fairly straightforward to port the device drivers from FreeBSD that do this as a PCI device -- attach the Xen PCI bridge that hangs off a PV timekeeping device by doing the CPUID probing and establishing a PV timesource even from within an HVM guest. It would avoid the need for the time accuracy calculation that Martin suggested (on a virtual environment only of course). -anil
