linux-kernel - Re: Qemu v9.0.2: Boot failed qemu-arm with Linux next-20241017 tag.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <16c7546e-ab87-4da7-bc36-14723675dba3@app.fastmail.com>
Date: Thu, 24 Oct 2024 08:08:53 +0000
From: "Arnd Bergmann" <arnd@...db.de>
To: Alex Bennée <alex.bennee@...aro.org>
Cc: "Naresh Kamboju" <naresh.kamboju@...aro.org>,
 "open list" <linux-kernel@...r.kernel.org>,
 "Linux ARM" <linux-arm-kernel@...ts.infradead.org>,
 lkft-triage@...ts.linaro.org,
 "Linux Regressions" <regressions@...ts.linux.dev>, qemu-devel@...gnu.org,
 "Mark Brown" <broonie@...nel.org>,
 "Catalin Marinas" <catalin.marinas@....com>,
 "Aishwarya TCV" <Aishwarya.TCV@....com>,
 "Peter Maydell" <peter.maydell@...aro.org>,
 "Anders Roxell" <anders.roxell@...aro.org>,
 "Vincenzo Frascino" <vincenzo.frascino@....com>,
 "Thomas Gleixner" <tglx@...utronix.de>,
 "Geert Uytterhoeven" <geert@...ux-m68k.org>
Subject: Re: Qemu v9.0.2: Boot failed qemu-arm with Linux next-20241017 tag.

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