On Fri, May 12, 2023 at 11:07:56PM +0200, Thomas Gleixner wrote: > From: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > > Implement the validation function which tells the core code whether > parallel bringup is possible. > > The only condition for now is that the kernel does not run in an encrypted > guest as these will trap the RDMSR via #VC, which cannot be handled at that > point in early startup. > > There was an earlier variant for AMD-SEV which used the GHBC protocol for > retrieving the APIC ID via CPUID, but there is no guarantee that the > initial APIC ID in CPUID is the same as the real APIC ID. There is no > enforcement from the secure firmware and the hypervisor can assign APIC IDs > as it sees fit as long as the ACPI/MADT table is consistent with that > assignment. > > Unfortunately there is no RDMSR GHCB protocol at the moment, so enabling > AMD-SEV guests for parallel startup needs some more thought. One option, other than adding said protocol, would be to: - use the APICID from CPUID -- with the expectation that it can be wrong. - (ab)use one of the high bits in cpuid_to_apicid[] as a test-and-set trylock. This avoids two CPUs from using the same per-cpu base, if CPUID is being malicious. Panic on fail. - validate against MSR the moment we can and panic if not matching The trylock ensures the stacks/percpu state is not used by multiple CPUs, and should guarantee a coherent state to get far enough along to be able to do the #VE inducing RDMSR.
