From: Reinette Chatre <reinette.chatre@intel.com>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Muhammad Usama Anjum" <Usama.Anjum@collabora.com>
Cc: "Fenghua Yu" <fenghua.yu@intel.com>,
"Shaopeng Tan" <tan.shaopeng@jp.fujitsu.com>,
kernel@collabora.com, "Shuah Khan" <skhan@linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-kselftest@vger.kernel.org,
"Maciej Wieczór-Retman" <maciej.wieczor-retman@intel.com>
Subject: Re: [PATCH] selftests: resctrl: ignore builds for unsupported architectures
Date: Mon, 12 Aug 2024 13:36:16 -0700 [thread overview]
Message-ID: <db16db55-5f68-484f-ba9f-3312b41bf426@intel.com> (raw)
In-Reply-To: <f7593344-203a-8e73-d53e-574ca511d003@linux.intel.com>
On 8/9/24 1:45 AM, 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?
>
> 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)?
>
It is not obvious to me that resctrl needs those "trivial program" compile
tests. For testing the target architecture ARCH seems appropriate. I do not
think it is guaranteed that ARCH will always be set though so the Makefile
may need an additional snippet to set ARCH to "uname -m" if it is not provided by
environment, similar to what is done in other Makefiles.
Reinette
next prev parent reply other threads:[~2024-08-12 20:36 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 [this message]
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
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=db16db55-5f68-484f-ba9f-3312b41bf426@intel.com \
--to=reinette.chatre@intel.com \
--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=skhan@linuxfoundation.org \
--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