[Bug 256781] EC2 Nitro: TSC-low timecounter lags

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256781

--- Comment #43 from dwmw2@infradead.org ---
I suspect Linux doesn't use that because it was only ever *proposed* as a
generic standard (by VMware) in https://lkml.org/lkml/2008/10/1/246 and seemed
to get shot down? It never actually got adopted by KVM, and it's strictly wrong
for a guest to look at 0x40000010 under anything but VMware, I think? I
certainly wouldn't look at it it under Hyper-V (and EC2 doesn't expose it, for
Windows instances when EC2 puts the Hyper-V leaves at 0x40000000 and the KVM
leaves at 0x40000100).

Looking back, I actually *approved* that commit to add it in EC2 without
realising that it wasn't really a standard. Bad Dave, no biscuit!

That said, it's probably a bad idea for any hypervisor to start using
0x40000010 for anything *else* at this point. And KVM might as well adopt it
(so we should add it to QEMU. And I note bhyve doesn't expose it either.)

Amusingly, even on VMware, Linux uses a hypercall to get the TSC frequency
instead.

Under KVM, Linux gets the information from the KVM clock. It might be slightly
less accurate because it needs to reverse-engineer the divide/shift fields to
get it though. So I think I'll make it use 0x40000010. Thanks for pointing it
out!

Xen puts it in leaf 040000x03 btw.

-- 
You are receiving this mail because:
You are the assignee for the bug.