On 10/13/15 19:06, Tim Lewis wrote: > Laszlo, > > The PI specification describes DynamicEx PCDs. The PCD protocol is in PI: > volume 3, chapter 8. > > All other PCDs are EDK2 artifacts, although some bits have drifted into the > packaging specification.
I was 98% sure I'd be wrong about PCD's: whenever I make a statement about them, someone who knows better corrects me. But that's how I learn, and elicit educational comments. So thank you for the correction! :) Laszlo > > Tim > > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo > Ersek > Sent: Tuesday, October 13, 2015 10:03 AM > To: Paolo Bonzini <pbonz...@redhat.com>; Brian J. Johnson <bjohn...@sgi.com>; > edk2-de...@ml01.01.org > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Jiewen Yao > <jiewen....@intel.com> > Subject: Re: [edk2] [PATCH v2 11/41] OvmfPkg: implement > EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER > > 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 > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
