Re: [kvm-unit-tests PATCH 16/16] add IPI loss stress test

[Sean Christopherson <seanjc@google.com>]

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@google.com
> 
> 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 :-)