On Mon, Oct 03, 2022, Sean Christopherson wrote: > On Mon, Oct 03, 2022, Vitaly Kuznetsov wrote: > > Sean Christopherson <seanjc@xxxxxxxxxx> writes: > > > And if you really need a udelay() and not a > > > usleep(), IMO it's worth adding exactly that instead of throwing NOPs at the CPU. > > > E.g. aarch64 KVM selftests already implements udelay(), so adding an x86 variant > > > would move us one step closer to being able to use it in common tests. > > > > ... so yes, I think we need a delay. The problem with implementing > > udelay() is that TSC frequency is unknown. We can get it from kvmclock > > but setting up kvmclock pages for all selftests looks like an > > overkill. Hyper-V emulation gives us HV_X64_MSR_TSC_FREQUENCY but that's > > not generic enough. Alternatively, we can use KVM_GET_TSC_KHZ when > > creating a vCPU but we'll need to pass the value to guest code somehow. > > AFAIR, we can use CPUID.0x15 and/or MSR_PLATFORM_INFO (0xce) or even > > introduce a PV MSR for our purposes -- or am I missing an obvious "easy" > > solution? > > I don't think you're missing anything. Getting the value into the guest is the > biggest issue. > > Vishal is solving a similar problem where the guest needs to know the "native" > hypercall. We can piggyback that hook to do KVM_GET_TSC_KHZ there during VM > creation, and then simply define udelay()'s behavior to always operate on the > "default" frequency. I.e. if a test wants to change the frequency _and_ use > udelay() _and_ cares about the precision of udelay(), then that test can go write > its own code. Forgot to connect the dots: https://lore.kernel.org/all/YzsC4ibDqGh5qaP9@xxxxxxxxxx
