On Fri, Sep 13, 2019 at 10:15 AM Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > > On Fri, Sep 13, 2019 at 09:26:04AM -0700, Jim Mattson wrote: > > On Fri, Sep 13, 2019 at 8:24 AM Sean Christopherson > > <sean.j.christopherson@xxxxxxxxx> wrote: > > > > > This is a misleading name, e.g. it took me quite a while to realize this > > > is testing only the passing scenario. For me, "limit test" implies that > > > it'd be deliberately exceeding the limit, or at least testing both the > > > passing and failing cases. I suppose we can't easily test the VMX abort > > > cases, but we can at least test VM_ENTER_LOAD. > > > > It's hard to test for "undefined behavior may result." :-) > > Fortune favors the bold? > > > One could check to see if the test is running under KVM, and then > > check for the behavior that Marc's other patch introduces, but even > > that is implementation-dependent. > > Hmm, what if kvm-unit-tests accepts both VM-Enter success and fail as > passing conditions? We can at least verify KVM doesn't explode, and if > VM-Enter fails, that the exit qual is correct. > > The SDM state that the max is a recommendation, which leads me to believe > that bare metal will work just fine if the software exceeds the > recommended max by an entry or two, but can run into trouble if the list > is ludicrously big. There's no way the CPU is tuned so finely that it > works at N but fails at N+1. It would have been nice if the hardware designers had seen fit to architect a hard failure at N+1, but I guess that ship sailed long ago. :-(
