From: Felix Kuehling <felix.kuehling@amd.com>
To: David Gow <davidgow@google.com>, Jeff Dike <jdike@addtoit.com>,
Richard Weinberger <richard@nod.at>,
Anton Ivanov <anton.ivanov@cambridgegreys.com>,
Shuah Khan <skhan@linuxfoundation.org>,
Brendan Higgins <brendanhiggins@google.com>,
Randy Dunlap <rdunlap@infradead.org>
Cc: linux-um@lists.infradead.org, amd-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, kunit-dev@googlegroups.com,
linux-kselftest@vger.kernel.org, linux-rdma@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] drm/amdgpu: Fix compilation under UML
Date: Fri, 18 Feb 2022 11:39:05 -0500 [thread overview]
Message-ID: <ef8eee23-ba8c-e76a-d32d-68658841708d@amd.com> (raw)
In-Reply-To: <20220218075727.2737623-2-davidgow@google.com>
Am 2022-02-18 um 02:57 schrieb David Gow:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> cpuinfo_x86 and its associated macros are not available under ARCH=um,
> even though CONFIG_X86_64 is defined.
>
> This patch (and discussion) were originally posted here:
> https://lkml.org/lkml/2022/1/24/1547
>
> This produces the following build errors:
> ../drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1556:9: note: in expansion of macro ‘cpu_data’
> return cpu_data(first_cpu_of_numa_node).apicid;
> ^~~~~~~~
> ../drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1560:1: error: control reaches end of non-void function [-Werror=return-type]
>
> ../drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.c: In function ‘kfd_fill_iolink_info_for_cpu’:
> ../arch/um/include/asm/processor-generic.h:103:19: error: called object is not a function or function pointer
> #define cpu_data (&boot_cpu_data)
> ~^~~~~~~~~~~~~~~
> ../drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.c:1688:27: note: in expansion of macro ‘cpu_data’
> struct cpuinfo_x86 *c = &cpu_data(0);
> ^~~~~~~~
> ../drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.c:1691:7: error: dereferencing pointer to incomplete type ‘struct cpuinfo_x86’
> if (c->x86_vendor == X86_VENDOR_AMD)
> ^~
> ../drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.c:1691:23: error: ‘X86_VENDOR_AMD’ undeclared (first use in this function); did you mean ‘X86_VENDOR_ANY’?
> if (c->x86_vendor == X86_VENDOR_AMD)
> ^~~~~~~~~~~~~~
> X86_VENDOR_ANY
>
> ../drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.c: In function ‘kfd_create_vcrat_image_cpu’:
> ../drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.c:1742:11: warning: unused variable ‘entries’ [-Wunused-variable]
> uint32_t entries = 0;
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: David Gow <davidgow@google.com>
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 6 +++---
> drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> index 9624bbe8b501..b1e2d117be3d 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> @@ -1682,7 +1682,7 @@ static int kfd_fill_mem_info_for_cpu(int numa_node_id, int *avail_size,
> return 0;
> }
>
> -#ifdef CONFIG_X86_64
> +#if defined(CONFIG_X86_64) && !defined(CONFIG_UML)
I don't think it makes sense to compile a hardware device driver in a
UML config. Instead of scattering UML #ifdefs through our code, I would
recommend adding this to Kconfig:
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -254,7 +254,7 @@ source "drivers/gpu/drm/radeon/Kconfig"
config DRM_AMDGPU
tristate "AMD GPU"
- depends on DRM && PCI && MMU
+ depends on DRM && PCI && MMU && !UML
select FW_LOADER
select DRM_KMS_HELPER
select DRM_SCHED
That would address patch 2 of this series as well.
Regards,
Felix
> static int kfd_fill_iolink_info_for_cpu(int numa_node_id, int *avail_size,
> uint32_t *num_entries,
> struct crat_subtype_iolink *sub_type_hdr)
> @@ -1741,7 +1741,7 @@ static int kfd_create_vcrat_image_cpu(void *pcrat_image, size_t *size)
> struct crat_subtype_generic *sub_type_hdr;
> int avail_size = *size;
> int numa_node_id;
> -#ifdef CONFIG_X86_64
> +#if defined(CONFIG_X86_64) && !defined(CONFIG_UML)
> uint32_t entries = 0;
> #endif
> int ret = 0;
> @@ -1806,7 +1806,7 @@ static int kfd_create_vcrat_image_cpu(void *pcrat_image, size_t *size)
> sub_type_hdr->length);
>
> /* Fill in Subtype: IO Link */
> -#ifdef CONFIG_X86_64
> +#if defined(CONFIG_X86_64) && !defined(CONFIG_UML)
> ret = kfd_fill_iolink_info_for_cpu(numa_node_id, &avail_size,
> &entries,
> (struct crat_subtype_iolink *)sub_type_hdr);
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> index 948fbb39336e..b38fc530ffe2 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> @@ -1552,7 +1552,7 @@ static int kfd_cpumask_to_apic_id(const struct cpumask *cpumask)
> first_cpu_of_numa_node = cpumask_first(cpumask);
> if (first_cpu_of_numa_node >= nr_cpu_ids)
> return -1;
> -#ifdef CONFIG_X86_64
> +#if defined(CONFIG_X86_64) && !defined(CONFIG_UML)
> return cpu_data(first_cpu_of_numa_node).apicid;
> #else
> return first_cpu_of_numa_node;
next prev parent reply other threads:[~2022-02-18 16:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-18 7:57 [PATCH 0/4] kunit,um: Fix kunit.py build --alltests David Gow
2022-02-18 7:57 ` [PATCH 1/4] drm/amdgpu: Fix compilation under UML David Gow
2022-02-18 16:39 ` Felix Kuehling [this message]
2022-02-18 16:40 ` Alex Deucher
2022-02-19 8:00 ` David Gow
2022-02-18 7:57 ` [PATCH 2/4] drm/amdgpu: Make smu7_hwmgr build on UML David Gow
2022-02-18 7:57 ` [PATCH 3/4] IB/qib: Compile under User-Mode Linux David Gow
2022-02-18 7:57 ` [PATCH 4/4] kunit: tool: Disable broken options for --alltests David Gow
2022-02-18 12:26 ` Johannes Berg
2022-02-19 8:00 ` David Gow
2022-02-19 15:43 ` Johannes Berg
2022-02-18 15:01 ` Jason Gunthorpe
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=ef8eee23-ba8c-e76a-d32d-68658841708d@amd.com \
--to=felix.kuehling@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=anton.ivanov@cambridgegreys.com \
--cc=brendanhiggins@google.com \
--cc=davidgow@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jdike@addtoit.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=rdunlap@infradead.org \
--cc=richard@nod.at \
--cc=skhan@linuxfoundation.org \
--cc=x86@kernel.org \
/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