On 10/13/15 18:53, Paolo Bonzini wrote: > > > 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.
EFI_SMM_CONTROL2_PROTOCOL is from the PI spec, not the UEFI spec. SmmCpuFeaturesLib is an edk2 artifact, not governed by PI. (But, of course, it might be sensible to require that *in edk2* the two be in sync!) > > PcdCpuSmmSyncMode is also not part of the UEFI spec, I guess? PCDs are also edk2 artifacts. In DXE they (the dynamic ones) are implemented with a protocol "of course", but that protocol is not specified in any industry standard. Thanks! Laszlo > > 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
