Perhaps there is a way to avoid the 3000:8000 startup vector. If a CPU is added after a cold reset, it is already in a different state because one of the active CPUs needs to release it by interacting

Could we have an initial SMBASE that is within TSEG. If we bring in hot plug CPUs one at a time, then initial SMBASE in TSEG can reprogram the SMBASE to the correct value for that CPU. Can we add a re

Paolo, It makes sense to match real HW. That puts us back to the reset vector and handling the initial SMI at 3000:8000. That is all workable from a FW implementation perspective. It look like the onl

Paolo, The SMBASE register is internal and cannot be directly accessed by any CPU. There is an SMBASE field that is member of the SMM Save State area and can only be modified from SMM and requires the

Laszlo, I believe all the code for the AP startup vector is already in edk2. It is a combination of the reset vector code in UefiCpuPkg/ResetVecor/Vtf0 and an IA32/X64 specific feature in the GenFv to

Paolo, It is my understanding that real HW hot plug uses the SDM defined methods. Meaning the initial SMI is to 3000:8000 and they rebase to TSEG in the first SMI. They must have chipset specific meth

Paolo, I find the following links related to the discussions here along with one example feature called GENPROTRANGE. https://csrc.nist.gov/CSRC/media/Presentations/The-Whole-is-Greater/images-media/d

Hi Jiewen, If a hot add CPU needs to run any code before the first SMI, I would recommend is only executes code from a write protected FLASH range without a stack and then wait for the first SMI. For

Hello, This is a proposal for a first step towards continuous integration for all TianoCore repositories to help improve to quality of commits and automate testing and release processes for all EDK II

Hi Michael, SCTs are in scope. It is only deciding when they get run and how much pre-commit execution time developers are willing to wait for a pass/fail result. The on-demand testing feature is one

Responses below. Mike

Sean, There may be many ways to improve the process and reduce the work maintainers perform. So these are ideas we can explore further going forward. I will add the concept of a non-maintainer opening

Hi Sean, This looks really good and I agree we can combine the RFCs and enable more pre-commits tests. Additional responses below. Mike

Hi Sean, Which OS/Compiler configurations are currently enabled for the Code Compilation Test? I have been working on enabling multiple OS/Compiler configurations in Azure Pipelines. There are some to

Hi Sean, For host based tests, I agree that VS2017 or VS2019 would be a good choice. Pick the one with the best coverage and easiest for developers to get feedback on the test results and test coverag

Nate and Amol, There is some work already started by Sean and Matt that implements a PEIM, DXE Driver, and SMM Driver to produce Protocol/PPI that wraps the BaseCryptLib services. This content broken

As Sean points out, different components in a platform may have different hash requirements. If we want to go down the path where we have a few modules that produce Protocols/PPIs for the BaseCryptLib

Hi Bret, Thanks for posting this content. Host based unit testing is a very valuable addition to the CI checks. I have the following comments: 1. I see that MdePkg adds a dependency on UnitTestPkg. Th

Hi Jiewen, Many of your responses are related to fuzz testing. Can we focus current infrastructure on host based unit testing and minimizing the content to support that testing type. Then, add a new s

Hi Bret, I am looking at the latest version of the content on your branch. I am confused by MdePkg/Test/MdePkgTest.dsc. It makes references to lib classes and packages that do not exist. CmockaLib|Cmo