Messages in this thread | | | Date | Tue, 2 Apr 2024 16:31:30 -0500 | Subject | Re: [PATCH] x86/sev: Apply RMP table fixups for kexec. | From | "Kalra, Ashish" <> |
| |
On 4/2/2024 4:20 PM, Borislav Petkov wrote: > 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 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 ? >> 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... >
| |