On Wed, 23 Oct 2024 at 20:47, Alex Bennée <alex.bennee(a)linaro.org> wrote:
> Agreed. However I think we were masking a calling issue that:
>
> /* Actual RAM size depends on initial RAM and device memory settings */
> [VIRT_MEM] = { GiB, LEGACY_RAMLIMIT_BYTES },
>
> And:
>
> -m 4G
>
> make no sense with no ARM_LPAE (which the kernel didn't have)
QEMU can't tell if the guest the user wants to boot
understands LPAE or not; it just provides the 4GB
of RAM, PCIe window above 4GB, etc, and describes them
in the dtb. It's up to the guest kernel to correctly
handle the >32bit addresses in the dtb, i.e. if it is
non-LPAE to ignore those resources it can't access
because they're out of range.
-- PMM
On Wed, Oct 23, 2024, at 19:47, Alex Bennée wrote:
>> On Sun, Oct 20, 2024, at 17:39, Naresh Kamboju wrote:
>> On non-LPAE arm32, this broke the existing behavior for
>> large 32-bit memory sizes. The obvious fix is to change
>> back the PAGE_MASK definition for 32-bit arm to a signed
>> number.
>
> Agreed. However I think we were masking a calling issue that:
>
> /* Actual RAM size depends on initial RAM and device memory settings */
> [VIRT_MEM] = { GiB, LEGACY_RAMLIMIT_BYTES },
>
> And:
>
> -m 4G
>
> make no sense with no ARM_LPAE (which the kernel didn't have) but if you
> pass -machine virt,gic-version=3,highmem=off (the default changed awhile
> back) you will get a warning:
>
> qemu-system-arm: Addressing limited to 32 bits, but memory exceeds it
> by 1073741824 bytes
>
> but I guess that didn't trigger for some reason before this patch?
I did not look at the full log, but I don't think there is a
problem between kernel and qemu, this is just a kernel regression
that can happen on any real or virtual platform with a lot of
memory.
I would guess that "highmem=off" was not even set here, so
there was probably no warning, and you would still see the
same kernel bug with qemu-system-aarch64 and its larger
limit for highmem=off.
Arnd
The following build regressions are noticed on x86 due to following
Warnings and errors with clang-19 and clang-nightly,
The builds with gcc-13 do PASS.
Started happening on next-20241023.
Good: next-20241022
Bad: next-20241023
Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org>
Build log:
—-------
drivers/acpi/prmt.c:156:29: error: passing 1-byte aligned argument to
4-byte aligned parameter 1 of 'efi_pa_va_lookup' may result in an
unaligned pointer access [-Werror,-Walign-mismatch]
156 | (void *)efi_pa_va_lookup(&th->guid,
handler_info->handler_address);
| ^
drivers/acpi/prmt.c:159:21: error: passing 1-byte aligned argument to
4-byte aligned parameter 1 of 'efi_pa_va_lookup' may result in an
unaligned pointer access [-Werror,-Walign-mismatch]
159 | efi_pa_va_lookup(&th->guid,
handler_info->static_data_buffer_address);
| ^
drivers/acpi/prmt.c:162:21: error: passing 1-byte aligned argument to
4-byte aligned parameter 1 of 'efi_pa_va_lookup' may result in an
unaligned pointer access [-Werror,-Walign-mismatch]
162 | efi_pa_va_lookup(&th->guid,
handler_info->acpi_param_buffer_address);
| ^
3 errors generated.
Suspecting commit:
ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context
Commit id: 088984c8d54c0053fc4ae606981291d741c5924b
Build Links:
—---
build error link:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2npIm4ZOkWenPJ71UOZG…
Metadata:
—----
Git_describe: next-20241023
Git_repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Git_sha: ceab669fdf7b7510b4e4997b33d6f66e433a96db
Build_name: clang-nightly-lkftconfig
Compiler: clang-nightly
Config: https://storage.tuxsuite.com/public/linaro/lkft/builds/2npIm4ZOkWenPJ71UOZG…
Download_url:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2npIm4ZOkWenPJ71UOZG…
--
Linaro LKFT
https://lkft.linaro.org