Like Xu <like.xu.linux@xxxxxxxxx> writes: > On 19/5/2022 9:31 pm, Like Xu wrote: >> ==== Test Assertion Failure ==== >> lib/x86_64/processor.c:1207: r == nmsrs >> pid=6702 tid=6702 errno=7 - Argument list too long >> 1 0x000000000040da11: vcpu_save_state at processor.c:1207 >> (discriminator 4) >> 2 0x00000000004024e5: main at state_test.c:209 (discriminator 6) >> 3 0x00007f9f48c2d55f: ?? ??:0 >> 4 0x00007f9f48c2d60b: ?? ??:0 >> 5 0x00000000004026d4: _start at ??:? >> Unexpected result from KVM_GET_MSRS, r: 29 (failed MSR was 0x3f1) >> >> I don't think any of these failing tests care about MSR_IA32_PEBS_ENABLE >> in particular, they're just trying to do KVM_GET_MSRS/KVM_SET_MSRS. > > One of the lessons I learned here is that the members of msrs_to_save_all[] > are part of the KVM ABI. We don't add feature-related MSRs until the last > step of the KVM exposure feature (in this case, adding MSR_IA32_PEBS_ENABLE, > MSR_IA32_DS_AREA, MSR_PEBS_DATA_CFG to msrs_to_save_all[] should take > effect along with exposing the CPUID bits). AFAIR the basic rule here is that whatever gets returned with KVM_GET_MSR_INDEX_LIST can be passed to KVM_GET_MSRS and read successfully by the host (not necessarily by the guest) so my guess is that MSR_IA32_PEBS_ENABLE is now returned in KVM_GET_MSR_INDEX_LIST but can't be read with KVM_GET_MSRS. Later, the expectation is that what was returned by KVM_GET_MSRS can be set successfully with KVM_SET_MSRS. -- Vitaly
