Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Shuah Khan <skhan@linuxfoundation.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Reinette Chatre" <reinette.chatre@intel.com>
Cc: "Muhammad Usama Anjum" <Usama.Anjum@collabora.com>,
	"Fenghua Yu" <fenghua.yu@intel.com>,
	"Shaopeng Tan" <tan.shaopeng@jp.fujitsu.com>,
	kernel@collabora.com, LKML <linux-kernel@vger.kernel.org>,
	linux-kselftest@vger.kernel.org,
	"Maciej Wieczór-Retman" <maciej.wieczor-retman@intel.com>,
	"Shuah Khan" <skhan@linuxfoundation.org>
Subject: Re: [PATCH] selftests: resctrl: ignore builds for unsupported architectures
Date: Tue, 13 Aug 2024 02:27:19 -0600	[thread overview]
Message-ID: <f23c3b11-5fd3-4c9e-8920-bdc43f4e5113@linuxfoundation.org> (raw)
In-Reply-To: <da87fe73-c39d-8b60-753d-7735c9abf569@linux.intel.com>

On 8/13/24 01:39, Ilpo Järvinen wrote:
> On Mon, 12 Aug 2024, Reinette Chatre wrote:
>> On 8/12/24 3:49 PM, Shuah Khan wrote:
>>> On 8/9/24 02:45, Ilpo Järvinen wrote:
>>>> Adding Maciej.
>>>>
>>>> On Fri, 9 Aug 2024, Muhammad Usama Anjum wrote:
>>>>> On 8/9/24 12:23 PM, Ilpo Järvinen wrote:
>>>>>> On Fri, 9 Aug 2024, Muhammad Usama Anjum wrote:
>>>>>>
>>>>>>> This test doesn't have support for other architectures. Altough
>>>>>>> resctrl
>>>>>>> is supported on x86 and ARM, but arch_supports_noncont_cat() shows
>>>>>>> that
>>>>>>> only x86 for AMD and Intel are supported by the test.
>>>>>>
>>>>>> One does not follow from the other. arch_supports_noncont_cat() is
>>>>>> only
>>>>>> small part of the tests so saying "This test" based on a small subset
>>>>>> of
>>>>>> all tests is bogus. Also, I don't see any reason why ARCH_ARM could
>>>>>> not be
>>>>>> added and arch_supports_noncont_cat() adapted accordingly.
>>>>> I'm not familiar with resctrl and the architectural part of it. Feel
>>>>> free to fix it and ignore this patch.
>>>>>
>>>>> If more things are missing than just adjusting
>>>>> arch_supports_noncont_cat(), the test should be turned off until proper
>>>>> support is added to the test.
>>>>>
>>>>>>> We get build
>>>>>>> errors when built for ARM and ARM64.
>>>>>>
>>>>>> As this seems the real reason, please quote any errors when you use
>>>>>> them
>>>>>> as justification so it can be reviewed if the reasoning is sound or
>>>>>> not.
>>>>>
>>>>>     CC       resctrl_tests
>>>>> 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:323:6:
>>>>> ../kselftest.h:74:9: error: impossible constraint in 'asm'
>>>>>      74 |         __asm__ __volatile__ ("cpuid\n\t"
>>>>>          \
>>>>>         |         ^~~~~~~
>>>>> cat_test.c:301:17: note: in expansion of macro '__cpuid_count'
>>>>>     301 |                 __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:303:17: note: in expansion of macro '__cpuid_count'
>>>>>     303 |                 __cpuid_count(0x10, 2, eax, ebx, ecx, edx);
>>>>>         |                 ^~~~~~~~~~~~~
>>>>
>>>> Okay, so it's specific to lack of CPUID. This seems a kselftest common
>>>> level problem to me, since __cpuid_count() is provided in kselftest.h.
>>>>
>>>> Shuah (or others), what is the intended mechanism for selftests to know if
>>>> it can be used or not since as is, it's always defined?
>>> _cpuid_count() gets defined in ksefltest.h if it can't find it.
>>>
>>> As the comment says both gcc and cland probide __cpuid_count()
>>>
>>>     gcc cpuid.h provides __cpuid_count() since v4.4.
>>>     Clang/LLVM cpuid.h provides  __cpuid_count() since v3.4.0.
>>>
>>>>
>>>> I see some Makefiles use compile testing a trivial program to decide
>>>> whether
>>>> they build some x86_64 tests or not. Is that what should be done here too,
>>>> test if __cpuid_count() compiles or not (and then build some #ifdeffery
>>>> based on the result of that compile testing)?
>>>>
>>>
>>> These build errors need to be fixed instead of restricting the build> In
>>> some cases when the test can't be supported on an architecture then it is
>>> okay
>>> to suppress build. This is not a general solution to suppress build warnings
>>
>> While there is an effort to support Arm in resctrl [1], this is not currently
>> the case and the resctrl selftests as a consequence only support x86 with
>> built-in assumptions that a test runs on either AMD or Intel. After the kernel
>> gains support
>> for Arm more changes will be needed for the resctrl tests to support another
>> architecture
>> so I do think the most appropriate change to address this build failure is to
>> restrict
>> resctrl tests to x86.
> 
> While ARM lacks resctrl support at the moment (the patch BTW claims
> otherwise), this problem is general-level problem in selftests. When
> somebody includes kselftest.h, the header provided __cpuid_count() which
> seems to not be compilable on ARMs (even if the test itself would never
> call it on other than when running on Intel). Some #ifdeffery is necessary
> either in kselftest.h or in the test code.
> 
>>> I would recommend against adding suppress build code when it can be fixed.
>>
>> I expect after resctrl fs obtains support for Arm the resctrl selftests can be
>> updated to support it with more fine grained architectural checks than a
>> global
>> enable/disable needed at this time.
> 
> That won't help to a build failure. The build would fail on ARM even if
> there's some resctrl specific test for arch done by the test itself.

I see.
   
> 
>>> Let's investigate this problem to fix it properly. I don't see any arm and
>>> arm64
>>> maintainers and developers on this thread. It would be good to investigate
>>> to
>>> see if this can be fixed.
> 
> Yes, I was hoping there would be a general level solution which would
> provide e.g. HAS_CPUID_COUNT or an empty stub for __cpuid_count() or
> something along those lines.
Can we try to make this change?

thanks,
-- Shuah



  reply	other threads:[~2024-08-13  8:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-09  7:10 [PATCH] selftests: resctrl: ignore builds for unsupported architectures Muhammad Usama Anjum
2024-08-09  7:23 ` Ilpo Järvinen
2024-08-09  8:05   ` Muhammad Usama Anjum
2024-08-09  8:45     ` Ilpo Järvinen
2024-08-12 20:36       ` Reinette Chatre
2024-08-12 22:49       ` Shuah Khan
2024-08-13  0:05         ` Reinette Chatre
2024-08-13  7:39           ` Ilpo Järvinen
2024-08-13  8:27             ` Shuah Khan [this message]
2024-08-13  8:25           ` Shuah Khan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f23c3b11-5fd3-4c9e-8920-bdc43f4e5113@linuxfoundation.org \
    --to=skhan@linuxfoundation.org \
    --cc=Usama.Anjum@collabora.com \
    --cc=fenghua.yu@intel.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=maciej.wieczor-retman@intel.com \
    --cc=reinette.chatre@intel.com \
    --cc=tan.shaopeng@jp.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox