On Mon, Oct 03, 2022, Vitaly Kuznetsov wrote: > Sean Christopherson <seanjc@xxxxxxxxxx> writes: > > Anyways, why not do e.g. usleep(1)? > > I was under the impression that all these 'sleep' functions result in a > syscall (and I do see TRIPLE_FAULT when I swap my rep_nop() with usleep()) > and here we need to wait in the guest (sender) ... Oh, duh, guest code. > > 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. > I'm thinking about being lazy here and implemnting a Hyper-V specific > udelay through HV_X64_MSR_TSC_FREQUENCY (unless you object, of course) > to avoid bloating this series beyond 46 patches it already has. I'm totally fine being even lazier here and just using a loop of nops, but with a different function name and a TODO (I completely forgot this was guest code when making the usleep() suggestion). Then we can clean up the TODO via udelay() in a follow-up series.
