Re: commit 7ffb791423c7 breaks steam game

[Balbir Singh <balbirs@nvidia.com>]

On 3/13/25 21:53, Bert Karwatzki wrote:
> Am Donnerstag, dem 13.03.2025 um 21:40 +1100 schrieb Balbir Singh:
>> 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.
> 
> According to /proc/cpuinfo my CPU has 48 phsical address bits:

Thanks, that is helpful

Looking at /proc/iomem

      fc00000000-fe0fffffff : PCI Bus 0000:03
        fc00000000-fdffffffff : 0000:03:00.0
        fe00000000-fe0fffffff : 0000:03:00.0

This makes sense and matches the BAR address ranges in the
lspci output

...
3ffe00000000-3fffffffffff : 0000:03:00.0
is interesting

Anyway, I think the nokaslr result is interesting, it seems like with nokaslr
even the older kernels have problems with the game

Could you confirm if with nokaslr

1. Only one single game stellaris is not working?
2. The entire laptop does not work?
3. Laptop works and other games work? Just one game is not working as expected?

Balbir Singh