Re: commit 7ffb791423c7 breaks steam game

[Balbir Singh <balbirs@nvidia.com>]

On 3/13/25 20:22, Bert Karwatzki wrote:
> Am Mittwoch, dem 12.03.2025 um 12:24 +1100 schrieb Balbir Singh:
>>>>
>>>>>
>>>>> As a sidenote, I've tested several kernel with nokaslr as command line parameter
>>>>> (6.1.128, 6.8.12, 6.12.17 (the debian sid distributional kernel)) and nokaslr is
>>>>> not recognized as a command line parameter in any of them
>>>>>
>>>>
>>>> Please see my comment above about booting. How did you check if nokaslr is being
>>>> recognized, is it via looking up dmesg?
>>>>
>>> When I boot with nokaslr I get the following messages in dmesg
>>> [    T0] Unknown kernel command line parameters "nokaslr
>>> BOOT_IMAGE=/boot/vmlinuz-6.14.0-rc5-next-20250307-master", will be passed to
>>> user space.
>>>
>>> This also happens when I use the debian kernel with standard .config
>>
>> That is quite strange, I can see nokaslr handling in choose_random_location() in
>> arch/x86/boot/compressed/kaslr.c (which depends on CONFIG_RANDOMIZE_BASE)
>>
>> Thanks,
>> Balbir
> 
> The command line parameter nokaslr does actually work, I tested that by booting
> the kernel with and without nokaslr and checked /proc/iomem for the physical
> address of the kernel. With nokalsr it's always at 0x1200000.
> 
> The warning message in the code
> 	if (cmdline_find_option_bool("nokaslr")) {
> 		warn("KASLR disabled: 'nokaslr' on cmdline.");
> 		return;
> 	}
> on the other hand is not shown, because warn is basically __putstr() which
> outputs to the serial console and the screen, not the log buffer (Which we do
> not have this early in boot anyway, I assume).
> 
> So with this solved I tested stellaris with a kernel without CONFIG_PCI_P2PDMA
> and nokaslr and found the same buggy behaviour (i.e. laggy input while stellaris
> is running).
> 
Thanks, the system/game is not working correctly accessing memory at 64 TiB

I am beginning to wonder what your physical address bits are set to?
I can't figure out from lspci, the capabilities of the iommu on your laptop

Could you please share your full dmesg/lspci before and after the patch/nokaslr
command line. 

Here is the what I know so far and based on some search I did, I could find
your laptop might have a CPU like this one
https://openbenchmarking.org/s/AMD+Ryzen+7+3750H

It has 43 bits of physical address and sev supported and IIRC sev can change the
amount of physical memory accessible, but I am surprised to see that 0xaff...
which is the 10TiB range is accessible (44 bits) and the 64 TiB may not be.
I am keen to know if the system works or is it just the game that is sluggiesh?
Does graphics work in general, do other games work?

The arch/x86/mm code assumes we have 46 or 52 bits of physically addressable
bits. There are experts who can correct me if I missed anything in my
analysis.

It seems like kaslr has been hiding the issue that exists on your laptop.

Balbir

PS: We could try some other experiments once we have the full dmesg and also get
help from other experts.