On 4/2/2024 4:20 PM, Borislav Petkov wrote:
The main issue is there is no API interface available to do that, i will need to add new API interfaces to update the e820_table_kexec and e820_table_firmware and then will that be acceptable for a use case which can be handled via a platform specific quirk ?On Tue, Apr 02, 2024 at 04:00:03PM -0500, Kalra, Ashish wrote:The main issue with doing that in snp_rmptable_init() is that there is no e820 API interfaces available to update the e820_table_kexec and e820_table_firmware and e820_table_firmware has already been exposed to sysfs.And? You can't change it later? Tried?
The e820 API only exports e820__range_update() which *only* fixes e820_table. The important point to note here is that in most cases BIOS would have reserved RMP table start and end aligned to 2M boundary and setup the e820 table which the BIOS passes to the kernel as such,So what was this "RMP table start and end physical range may not be aligned to 2MB" in your commit message? /me is completely confused now. Or does "most cases" mean that there can be cases where the RMP table placement in the BIOS is not 2M aligned and then the kexec kernel could try to allocate from within that chunk and there's RMP faults?
Yes exactly, that's what the above comment means. That's why the above commit message says "may".
And you want to allocate those chunks up to the 2M boundary unconditionally, regardless of SNP enablement?
My point is that we always keep the RMP table memory reserved regardless of SNP enablement, so these are simply fixups/adjustments on top of that reservation.
Thanks, Ashish
Now look at your original commit message and tell me how much of what came out on this thread, was in it? Not a lot, I'd say...
|