On 13/10/2015 18:49, Laszlo Ersek wrote: >> > >> > However, this (obviously) doesn't scale well, so Intel has been moving >> > towards signaling SMI to only a single processor, and avoiding the >> > machine-wide rendezvous when it isn't necessary. BIOS implementations >> > may be lagging behind. > But... when is it necessary? Paolo implied it might not be necessary for > us because MTRR changes are not relevant on our virtual platform -- > otherwise all CPUs would have to agree on the MTRR settings --, but > isn't there a security aspect to it as well?
MTRR changes are only needed on processors without SMRRs (which is 32 bits processors according to the default SmmCpuFeaturesLib). We don't have SMRRs, but we also are immune from caching issues because all of our memory mapping is done in the hypervisor and the processor sees it. On real hardware, it's done in the MCH (northbridge). In any case, it's all customizable through SmmCpuFeaturesLib. SmmCpuFeaturesLib and EFI_SMM_CONTROL2_PROTOCOL must be somehow in sync, which perhaps is why the UEFI spec doesn't go into details. PcdCpuSmmSyncMode is also not part of the UEFI spec, I guess? Paolo > All UefiCpuPkg/UefiCpuPkg.dec says is: > > ## Indicates the CPU synchronization method used when processing an SMI. > # 0x00 - Traditional CPU synchronization method.<BR> > # 0x01 - Relaxed CPU synchronization method.<BR> > # @Prompt SMM CPU Synchronization Method. > gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x00|UINT8|0x60000014 > > Uhm. Thanks?... I like it when the answer is in the code! :) Paolo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
