On 7/7/22 11:29, Scott Cheloha wrote:
On Thu, Jul 07, 2022 at 11:13:14AM +0900, Yuichiro NAITO wrote:
I had another try for the v3 patch that runs on FreeBSD bhyve.
In this case, I need the following patch for TSC to be chosen as a timecounter.
diff --git a/sys/arch/amd64/amd64/tsc.c b/sys/arch/amd64/amd64/tsc.c
index c4d3acda8c7..ab34df4463c 100644
--- a/sys/arch/amd64/amd64/tsc.c
+++ b/sys/arch/amd64/amd64/tsc.c
@@ -168,7 +168,7 @@ measure_tsc_freq(struct timecounter *tc)
min_freq = ULLONG_MAX;
- delay_usec = 100000;
+ delay_usec = 10000;
for (i = 0; i < 3; i++) {
s = intr_disable();
This is a separate issue from TSC synchronization.
I'll describe it in an another mail.
What are we using for delay_func when this function runs
on cpu0?
`i8254_delay` is used in the `measure_tsc_freq` execution time.
With this patch, Scott's v3 patch works fine on FreeBSD bhyve.
Here is dmesg shown in my OpenBSD.
This is an Intel machine. Does byhve not pass the TSC frequency
through the MSR? Or is there something special we need to do if
we're a guest to determine the frequency?
I'm not sure TSC frequency is offered via MSR.
`tsc_freq_cpuid` gets TSC frequency from CPUID 0x15.
It is disabled by bhyve.
So, OpenBSD kernel measures TSC frequency in `measure_tsc_freq` function.
But i8254_delay error is relatively large in this environment.
--
Yuichiro NAITO (naito.yuich...@gmail.com)
