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.
