On Thu, 2022-07-21 at 13:52 +1200, Kai Huang wrote: > > > BUT, since as the first step, we cannot get the CMR during kernel boot (as > > > it > > > requires additional code to put CPU into VMX operation), I think for now > > > we can > > > handle ACPI memory hotplug in below way: > > > > > > - For memory hot-removal, we do nothing. > > > > This doesn't seem right to me. *If* we get a known-bogus hot-remove > > event, we need to reject it. Remember, removal is a two-step process. > > If so, we need to reject the (CMR) memory offline. Or we just BUG() in the > ACPI > memory removal callback? > > But either way this will requires us to get the CMRs during kernel boot. > > Do you think we need to add this support in the first series? Hi Dave, In terms of whether we should get CMRs during kernel boot (which requires we do VMXON/VMXOFF during kernel boot around SEAMCALL), I forgot one thing: Technically, ACPI memory hotplug is related to whether TDX is enabled in BIOS, but not related to whether TDX module is loaded or not. With doing VMXON/VMXOFF, we can get CMRs during kernel boot by calling P-SEAMLDR's SEAMCALL. But theoretically, from TDX architecture's point of view, the P- SEAMLDR may not be loaded even TDX is enabled by BIOS (in practice, the P- SEAMLDR is always loaded by BIOS when TDX is enabled), in which case there's no way we can get CMRs. But in this case, I think we can just treat TDX isn't enabled by BIOS as kernel should never try to load P-SEAMLDR. Other advantages of being able to do VMXON/VMXOFF and getting CMRs during kernel boot: 1) We can just shut down the TDX module in kexec(); 2) We can choose to trim any non-CMR memory out of memblock.memory instead of having to manually verify all memory regions in memblock are CMR memory. Comments?
