On Thu, Oct 27, 2022, Maxim Levitsky wrote: > On Mon, 2022-10-24 at 17:19 +0000, Sean Christopherson wrote: > > That doesn't (and shouldn't) wake the vCPU from the guest's perspective. If/when > > userspace calls KVM_RUN again, the vCPU's state should still be KVM_MP_STATE_HALTED > > and thus KVM will invoke vcpu_block() until there is an actual wake event. > > Well HLT is allowed to do suprious wakeups so KVM is allowed to not do it correclty, I suspect the above "HLT is allowed to do spurious wakeups" is a typo, but in case it's not, the SDM says: An enabled interrupt (including NMI and SMI), a debug exception, the BINIT# signal, the INIT# signal, or the RESET# signal will resume execution. and the APM says: Execution resumes when an unmasked hardware interrupt (INTR), non-maskable interrupt (NMI), system management interrupt (SMI), RESET, or INIT occurs. I.e. resuming from HLT without a valid wake event is a violation of the x86 architecture. > > > In fact I'll just do it - just need to pick some open source PRNG code. > > > Do you happen to know a good one? Mersenne Twister? > > > > It probably makes sense to use whatever we end up using for selftests[*] in order > > to minimize the code we have to maintain. > > > > [*] https://lore.kernel.org/all/20221019221321.3033920-2-coltonlewis@xxxxxxxxxx > > Makes sense. I'll then just take this generator and adopt it to the kvm unit tests. > Or do you want to actually share the code? via a kernel header or something? Sadly, just copy+paste for now. It'd be nice to share code, e.g. for the myriad X86_FEATURE_* flags, but's a separate problem. > > > That is the problem - the delay is just in TSC freq units, and knowing TSC freq > > > for some reason on x86 is next to impossible on AMD > > > > Ah, delay() takes the number cycles. Ugh. > > > > We should fix that, e.g. use the CPUID-provided frequency when possible (KVM should > > emulate this if it doesn't already), and then #define an arbitrary TSC frequency as > > a fall back so that we can write readable code, e.g. 2.4Ghz is probably close enough > > to work. > > KVM doesn't emulate the Intel's specific way of reporting TSC freq on AMD. > In some sense this is wrong to do as it is Intel specific. > > I do think that it is a great idea to report the TSC freq via some KVM specific MSR. > That might though open a pandora box in regard to migration. Heh, yeah, the Hyper-V TSC stuff is rather ugly. > I don't like the 2.4Ghz idea at all - it is once again corner cutting. Its true > that most code doens't need exact delay, not to mention that delay is never going > to be exact, but once you expose (nano)second based interface, test writers > will start to use it, and then wonder why someone hardcoded it to 2.4 GHz.a True. A really crazy/bad idea would be to get APERF/MPERF from /dev/cpu/0/msr in the run script and somehow feed the host TSC into KUT :-)
