> On Dec 18, 2019, at 2:24 AM, Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > > On Fri, Dec 13, 2019 at 09:30:45AM -0800, Jim Mattson wrote: >> On Fri, Dec 13, 2019 at 1:13 AM Nadav Amit <nadav.amit@xxxxxxxxx> wrote: >>>> On Dec 13, 2019, at 12:59 AM, Jim Mattson <jmattson@xxxxxxxxxx> wrote: >>>> >>>> On Sat, May 18, 2019 at 4:58 PM Nadav Amit <nadav.amit@xxxxxxxxx> wrote: >>>>> The test that checks the maximum VMCS field encoding does not probe all >>>>> possible VMCS fields. As a result it might fail since the actual >>>>> IA32_VMX_VMCS_ENUM.MAX_INDEX would be higher than the expected value. >>>>> >>>>> Change the test to check that the maximum of the supported probed >>>>> VMCS fields is lower/equal than the actual reported >>>>> IA32_VMX_VMCS_ENUM.MAX_INDEX. >>>> >>>> Wouldn't it be better to probe all possible VMCS fields and keep the >>>> test for equality? >>> >>> It might take a while though… >>> >>> How about probing VMREAD/VMWRITE to MAX_INDEX in addition to all the known >>> VMCS fields and then checking for equation? >> It can't take that long. VMCS field encodings are only 15 bits, and >> you can ignore the "high" part of 64-bit fields, so that leaves only >> 14 bits. > > Unless kvm-unit-tests is being run in L1, in which case things like this > are painful. That being said, I do agree that probing "all" VMCS fields > is the way to go. Walking from highest->lowest probably won't even take > all that many VMREADS. If it is slow, the test can be binned to its own > config. Ok. I’ll send a patch for that.
