From: Ingo Molnar <mingo@kernel.org>
To: Balbir Singh <balbirs@nvidia.com>
Cc: "Bert Karwatzki" <spasswolf@web.de>,
"Christian König" <christian.koenig@amd.com>,
"Kees Cook" <kees@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Andy Lutomirski" <luto@kernel.org>,
"Alex Deucher" <alexander.deucher@amd.com>,
linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org
Subject: Re: commit 7ffb791423c7 breaks steam game
Date: Thu, 27 Mar 2025 11:53:18 +0100 [thread overview]
Message-ID: <Z-UuHkUPy60e1GWM@gmail.com> (raw)
In-Reply-To: <c6d996b4-5e44-4066-964c-5a2a27dfaa6a@nvidia.com>
* Balbir Singh <balbirs@nvidia.com> wrote:
> > Yes, turning off CONFIG_HSA_AMD_SVM fixes the issue, the strange memory
> > resource
> > afe00000000-affffffffff : 0000:03:00.0
> > is gone.
> >
> > If one would add a max_pyhs_addr argument to devm_request_free_mem_region()
> > (which return the resource addr in kgd2kfd_init_zone_device()) one could keep
> > the memory below the 44bit limit with CONFIG_HSA_AMD_SVM enabled.
> >
>
> Thanks for reporting the result, does this patch work
>
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 01ea7c6df303..14f42f8012ab 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -968,8 +968,9 @@ int add_pages(int nid, unsigned long start_pfn, unsigned long nr_pages,
> WARN_ON_ONCE(ret);
>
> /* update max_pfn, max_low_pfn and high_memory */
> - update_end_of_memory_vars(start_pfn << PAGE_SHIFT,
> - nr_pages << PAGE_SHIFT);
> + if (!params->pgmap)
> + update_end_of_memory_vars(start_pfn << PAGE_SHIFT,
> + nr_pages << PAGE_SHIFT);
>
> return ret;
> }
>
> It basically prevents max_pfn from moving when the inserted memory is
> zone_device.
>
> FYI: It's a test patch and will still create issues if the amount of
> present memory (physically) is very high, because the driver need to
> enable use_dma32 in that case.
So this patch does the trick for Bert, and I'm wondering what the best
fix here would be overall, because it's a tricky situation.
Am I correct in assuming that with enough physical memory this bug
would trigger, with and without nokaslr?
I *think* the best approach going forward would be to add the above
quirk the the x86 memory setup code, but also issue a kernel warning at
that point with all the relevant information included, so that the
driver's use_dma32 bug can at least be indicated?
That might also trigger for other systems, because if this scenario is
so spurious, I doubt it's the only affected driver ...
Thanks,
Ingo
next prev parent reply other threads:[~2025-03-27 10:53 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-22 12:23 commit 7ffb791423c7 breaks steam game Bert Karwatzki
2025-03-23 6:51 ` Balbir Singh
2025-03-24 11:23 ` Bert Karwatzki
2025-03-24 12:14 ` Christian König
2025-03-24 22:48 ` Balbir Singh
2025-03-25 7:35 ` Christian König
2025-03-25 22:45 ` Balbir Singh
2025-03-25 23:21 ` Bert Karwatzki
2025-03-25 23:43 ` Balbir Singh
2025-03-26 1:50 ` Balbir Singh
2025-03-26 10:10 ` Bert Karwatzki
2025-03-26 10:36 ` Balbir Singh
2025-03-26 11:14 ` Bert Karwatzki
2025-03-27 10:53 ` Ingo Molnar [this message]
2025-03-27 22:03 ` Balbir Singh
2025-03-24 21:43 ` Balbir Singh
-- strict thread matches above, loose matches on Subject: below --
2025-03-25 10:14 Bert Karwatzki
2025-03-25 12:23 ` Christian König
2025-03-26 22:00 ` Bert Karwatzki
2025-03-26 22:58 ` Linus Torvalds
2025-03-27 0:57 ` Balbir Singh
2025-03-27 0:58 ` Bert Karwatzki
2025-03-27 10:40 ` Ingo Molnar
2025-03-24 23:07 Bert Karwatzki
2025-03-25 8:36 ` Christian König
2025-03-25 10:25 ` Balbir Singh
2025-03-10 11:22 Bert Karwatzki
2025-03-10 21:48 ` Balbir Singh
2025-03-11 7:19 ` Balbir Singh
2025-03-11 7:28 ` Ingo Molnar
2025-03-11 11:15 ` Bert Karwatzki
2025-03-11 18:24 ` Bert Karwatzki
2025-03-11 22:10 ` Balbir Singh
2025-03-11 23:09 ` Bert Karwatzki
2025-03-12 0:26 ` Bert Karwatzki
2025-03-12 2:23 ` Balbir Singh
2025-03-12 1:24 ` Balbir Singh
2025-03-13 9:22 ` Bert Karwatzki
2025-03-13 10:40 ` Balbir Singh
2025-03-13 10:53 ` Bert Karwatzki
2025-03-13 11:47 ` Balbir Singh
2025-03-13 18:12 ` Bert Karwatzki
2025-03-13 21:54 ` Balbir Singh
2025-03-13 22:22 ` Bert Karwatzki
2025-03-14 6:14 ` Balbir Singh
2025-03-14 13:34 ` Balbir Singh
2025-03-14 14:18 ` Bert Karwatzki
2025-03-15 0:16 ` Balbir Singh
2025-03-15 17:40 ` Alex Deucher
2025-03-16 13:09 ` Bert Karwatzki
2025-03-16 20:06 ` Bert Karwatzki
2025-03-17 9:13 ` Balbir Singh
2025-03-20 9:01 ` Ingo Molnar
2025-03-20 23:55 ` Balbir Singh
2025-03-21 10:24 ` Ingo Molnar
2025-03-21 11:05 ` Balbir Singh
2025-03-22 8:04 ` Ingo Molnar
2025-03-22 9:40 ` Balbir Singh
2025-03-20 23:43 ` Bert Karwatzki
2025-03-21 4:55 ` Balbir Singh
2025-03-21 12:26 ` Bert Karwatzki
2025-03-22 2:06 ` Balbir Singh
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=Z-UuHkUPy60e1GWM@gmail.com \
--to=mingo@kernel.org \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=balbirs@nvidia.com \
--cc=bhelgaas@google.com \
--cc=christian.koenig@amd.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=spasswolf@web.de \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.