Hi, for this item <https://github.com/tianocore/edk2/issues/97>:
RFE: OvmfPkg: Set MSR_IA32_FEATURE_CONTROL by following QEMU fw_cfg file the goal is to do the following: - fetch a UINT64 value from QEMU via fw_cfg - write that UINT64 value to a specific MSR on *all* logical processors (BSP and all APs) - write the MSR on the normal boot path and the S3 resume boot path. I've been wrecking my brain on this. Everything I've come up with thus far looks convoluted and ugly (the multiprocessing part). I realize there is "UefiCpuPkg/CpuMpPei", producing EFI_PEI_MP_SERVICES_PPI. Do you guys think it would be appropriate for this purpose? We could add this driver to OVMF's PEI phase. And, add another PEIM that would: - depend on this PPI with a DEPEX, - fetch the UINT64 from fw-cfg, and call EFI_PEI_MP_SERVICES_PPI.StartupAllAPs()s to set the MSR. Not sure if we should add this client code to OvmfPkg/PlatformPei, due to the DEPEX. OvmfPkg/PlatformPei is the PEIM that installs the permanent PEI RAM, so if we added this DEPEX to it, that would force CpuMpPei to run from temporary PEI RAM. I don't know if that would be feasible. ... Actually, it would lead to a DEPEX circle: CpuMpPei explicitly depends on gEfiPeiMemoryDiscoveredPpiGuid (it can only run from permament PEI RAM). So a separate client PEIM for OvmfPkg would be mandatory. Another question is if I'd be allowed to call AsmWriteMsr64() in the AP routine (reading the UINT64 from a global variable or the main thread's stack via the ProcedureArgument pointer). That routine seems very small and self-contained, so I think assembly code would not be necessary. What do you guys think? Thanks! Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
