Date: Tue, 12 Aug 2025 14:57:00 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 256781] EC2 Nitro: TSC-low timecounter lags Message-ID: <bug-256781-27103-3JQV9PCCWz@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-256781-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-256781-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-256781-27103-3JQV9PCCWz>