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;
Message-ID: <be498c32-bed6-d31a-ae94-6006dd59ea1e@amd.com>
Date:   Mon, 18 Jul 2022 20:24:08 +0530
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [RFC FIX PATCH] x86/e820: Stop kernel boot when RAM resource
 reservation fails
Content-Language: en-US
To:     Boris Petkov <bp@alien8.de>, 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
References: <20220718085815.1943-1-bharata@amd.com>
 <E7A3FF43-C49F-415E-81C6-CD14F4107349@alien8.de>
From:   Bharata B Rao <bharata@amd.com>
In-Reply-To: <E7A3FF43-C49F-415E-81C6-CD14F4107349@alien8.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WWRMS25kSE4wRFluUjhISE9ZSDhZTnlyenp4bjZPUkRXVldEUzFWeGR1NWFX?=
 =?utf-8?B?N1AxTW9Wd2hLUE1LeE1qME1XZVNFa05LYVEwZ2RPMktRN0pwL1BMcmdjWTlO?=
 =?utf-8?B?L0g1ZS9BTFFldytvaGlEaklsc0UzQmxKblZTd0J5VWFWWFl1SCtEWFFVc1Yy?=
 =?utf-8?B?eEZOT0NLVmxtMVZLL3V6QVc0bjlkWnBQNFF3YlBuWmVtTzVRMENXT3RFMVBS?=
 =?utf-8?B?TzBCSlNSenRDT0lua0paejZ0dXlPTjZ2NUZJUDNvbXE0MElsM041V1FBUDg2?=
 =?utf-8?B?M1h4RFdTajZKTUZMTENNRTBiRkZRQ2tKNHVHV1Fkb0pOdEV5NkJQQmhnaE05?=
 =?utf-8?B?a2lwWlhFZTRDUDEydUNzVFBXNlNJSVJiRlFxS2o4WnR3SytWMXlENVlQck1s?=
 =?utf-8?B?dzdrYnJ5S0gxUTRHMzZGYUlEZlVwNEtYNVplU3d3VU1LeHRPWm1iQm4yY3Fl?=
 =?utf-8?B?NFdINXlMczJOMjBkakVpZkorL2ZpR3liSTRSNUFTR0NWNjJYQUlMdmdubURz?=
 =?utf-8?B?bWFKeTBOT2hQNlpUNWVFMEdHUGhQNHhuYkFiMzdVcGVvL3hjU3dhSVQ3SHhw?=
 =?utf-8?B?dHA1amJZcWd5Qm5iVE5XaHpILzdnYjgwckZSK3BGbFFSMlZvb294dTBFZVVk?=
 =?utf-8?B?ZHozNHM2SjBjLzVxREl4bm9yTEhWMG95cW9zTjlnZmtBRHdLTmlEeHVyQkxQ?=
 =?utf-8?B?QzRQSzV1SVUzMXA5Y0w5YUdoUXVaRjVmRHJiZGxJcHpMYTFLUjVJaVRTUEti?=
 =?utf-8?B?U1llbmlBV3dQSzJ2OWdMQWI4c3ptNzFSMzd6UjdsRzhXT2FmdmFnVDhUUjY4?=
 =?utf-8?B?cWJJWlpGUnVnZWZTanNJVlNITmhPanc3NDhuZDI5WjFmelhIaWYxMFQ5eVlR?=
 =?utf-8?B?NTNRSmRHVEF0clcxVzRlelhZVTlvczlKbXJ3VDZUUlNRT0s4WkJKSmVHWEFZ?=
 =?utf-8?B?TFpkMm84K0J6TkZCK1hVNjhIQnozSHg1TnJITFNnemkzR2wrWHNFVHJaa0d4?=
 =?utf-8?B?aGxHcjJoUEtITktnMCtZelg0SnVoSklyYWFhdC9HWjBhMU83V041OVk3OTVT?=
 =?utf-8?B?WVVhdnlMUk15a0k5blFRVGhaSHllZDhubFJZQm5LRGtHNmhWNXE3NTQ1by81?=
 =?utf-8?B?OFd3MDBpTUpHRjRSbGRiUm11Sm5Va3hVanpua29GK29OUVl5ZzY0b0VSUWl0?=
 =?utf-8?B?RUNCbUg0aGszK3MyYkl3ckJYNWExQ3JpNytadjJIZHJlU3JERE1yTVpnVVVC?=
 =?utf-8?B?cUFOUzRwSmtGN2RjOWlDSzFTMjJWUjZJYmFVbVFabUhqT1Y2L0hyQVU3ZkJJ?=
 =?utf-8?B?V0g4MGpWZXZTVDJaS0lSVkRlLzZMelFaczREWU43aXU2MEwyc2hxNmFCeVdW?=
 =?utf-8?B?VG81aVJncDJxUlp2alV0OTFFamJIUGR1WWhyOFU0M2lmck9NdnNHOVFFQlZr?=
 =?utf-8?B?ZUw0QjdZN056U3VGejNOeUNJVVF2bUpyd01vUHlKRm5VeVpjRlVoRFdUT3pC?=
 =?utf-8?B?YUh1Nk5CK2orN2xRanNWb2ovYndHOTA5RFhrNVlsS3JNZUN1QmVDSjFHZlFo?=
 =?utf-8?B?RnpxNVNGMVIwWk02OUhGbC9zcmc1R08wMmVvWjJWSWZ3SGNyYVBJMnVYK01F?=
 =?utf-8?B?TnByY1pCTWRsbHlKb1dROUdVNlFvcnM2WXR5cVpTaVNCWHBLdGJBeklFbkZ1?=
 =?utf-8?B?L1ZKNTk2c083OHpDS2VWOGdBTWwydUZsbzluY1ExaWozMzdzMVdjTTc3RENT?=
 =?utf-8?B?L1NySnRMMjNkVERIZ2locFczbXZ2emtwMHRHNEtvK2MxeEZVTGd2YkZGWHZV?=
 =?utf-8?B?MU0yc3gvbGxGRTNJdlg3THdKaEtXTkNKMjM1SkkreThoa2ZKMm9MZVF2QzI2?=
 =?utf-8?B?dnBFa0dqNWt4Zm9rVmZFRUlqc0laT284Y3QyS2FGK3JZNWt1UzRCMGZUVkhD?=
 =?utf-8?B?YjI1aUUrZVpnUEh0YVljbldjekNzWkVSaVU2NzduVzhWM0VUVVlheEtTcndz?=
 =?utf-8?B?eXdkTmYzclVBdFBjYmR5N3p0RkphaDdDdmpKRVVIeGJYVVQrQkpQRk9yNmtQ?=
 =?utf-8?B?NlQyWjRFNlVDeXhMZ3FUT2pNOXdjS1JTWXpMYlBVM3VlandCSlp2cEltTVpH?=
 =?utf-8?Q?R/O2kpAxmjpu1zeARR2StGw5p?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e69d27cf-8ef5-411c-f621-08da68cd644f
X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB6434.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jul 2022 14:54:19.0396
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: NezoSD31emXjMChBrXNvJlhrzxLLXDWBWE2RQH2QKRgal1AWHFEzcbR52y4X3qtB6QGbTN+Cf6csRzRQ0lem4A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6959
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 7/18/2022 4:12 PM, Boris Petkov wrote:
> On July 18, 2022 8:58:15 AM UTC, Bharata B Rao <bharata@amd.com> wrote:
>> Currently it is possible to start a guest with memory that
>> is beyond the addressable range of CPU. This can typically
>> be done by using QEMU without explicilty specifying the max
>> physical addressable bits (via phys-bits or host-phys-bits
>> options). In such cases QEMU will start the guest with more
>> than 1TB memory but would implicitly limit the phys-bits to 40.
> 
> Why does the upstream kernel care about some weird qemu guest configurations? 

It may be a weird guest configuration, but it looks like
a kernel bug exposed by QEMU.

Regards,
Bharata