On 9/6/24 04:12, Ilpo Järvinen wrote:
On Thu, 5 Sep 2024, Shuah Khan wrote:When resctrl is built on architectures without __cpuid_count() support, build fails. resctrl uses __cpuid_count() defined in kselftest.h. Even though the problem is seen while building resctrl on aarch64, this error can be seen on any platform that doesn't support CPUID. CPUID is a x86/x86-64 feature and code paths with CPUID asm commands will fail to build on all other architectures. All others tests call __cpuid_count() do so from x86/x86_64 code paths when _i386__ or __x86_64__ are defined. resctrl is an exception. Fix the problem by defining __cpuid_count() only when __i386__ or __x86_64__ are defined in kselftest.h and changing resctrl to call __cpuid_count() only when __i386__ or __x86_64__ are defined. In file included from resctrl.h:24, from cat_test.c:11: In function ‘arch_supports_noncont_cat’, inlined from ‘noncont_cat_run_test’ at cat_test.c:326:6: ../kselftest.h:74:9: error: impossible constraint in ‘asm’ 74 | __asm__ __volatile__ ("cpuid\n\t" \ | ^~~~~~~ cat_test.c:304:17: note: in expansion of macro ‘__cpuid_count’ 304 | __cpuid_count(0x10, 1, eax, ebx, ecx, edx); | ^~~~~~~~~~~~~ ../kselftest.h:74:9: error: impossible constraint in ‘asm’ 74 | __asm__ __volatile__ ("cpuid\n\t" \ | ^~~~~~~ cat_test.c:306:17: note: in expansion of macro ‘__cpuid_count’ 306 | __cpuid_count(0x10, 2, eax, ebx, ecx, edx); Reported-by: Muhammad Usama Anjum <usama.anjum@xxxxxxxxxxxxx> Reported-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx> Signed-off-by: Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>When the small things from Muhammad and Reinette addressed, this seems okay. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>
Will do. Thank you for the review.
Thanks for the solution. I'm still left to wonder if the x86 selftest is supposed to clobber CFLAGS? It seems that problem is orthogonal to this cpuid/resctrl problem. I mean this question from the perspective of coherency in the entire kselftest framework, lib.mk seems to want to adjust CFLAGS but those changes will get clobbered in the case of x86 selftest.
This isn't the case x86 clobbering the CFLAGS. This falls into the case of x86 customizing the flags for the test and the ones set by the common lib.mk might interfere with the flags it needs. There isn't anything here to fix based on the history of this test and lib.mk. thanks, -- Shuah
