Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 18 Jul 2022 10:42:13 +0000
From:   Boris Petkov <bp@alien8.de>
To:     Bharata B Rao <bharata@amd.com>, linux-kernel@vger.kernel.org
CC:     tglx@linutronix.de, mingo@redhat.com, x86@kernel.org,
        dave.hansen@linux.intel.com, nikunj@amd.com, hpa@zytor.com,
        Abraham.Shaju@amd.com
Subject: =?US-ASCII?Q?Re=3A_=5BRFC_FIX_PATCH=5D_x86/e820=3A_Stop_kernel?= =?US-ASCII?Q?_boot_when_RAM_resource_reservation_fails?=
In-Reply-To: <20220718085815.1943-1-bharata@amd.com>
References: <20220718085815.1943-1-bharata@amd.com>
Message-ID: <E7A3FF43-C49F-415E-81C6-CD14F4107349@alien8.de>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On July 18, 2022 8:58:15 AM UTC, Bharata B Rao <bharata@amd=2Ecom> wrote:
>Currently it is possible to start a guest with memory that
>is beyond the addressable range of CPU=2E This can typically
>be done by using QEMU without explicilty specifying the max
>physical addressable bits (via phys-bits or host-phys-bits
>options)=2E In such cases QEMU will start the guest with more
>than 1TB memory but would implicitly limit the phys-bits to 40=2E

Why does the upstream kernel care about some weird qemu guest configuratio=
ns?=20

--=20
Sent from a small device: formatting sux and brevity is inevitable=2E