Mike, as you mentioned we have been working towards enabling a practical and extensible CI for Edk2 using Azure dev ops and the recently added edk2-pytool infrastructure. We have been using similar

Hi Michael, would it make sense to run SCT (using UnixHost and/or qemu) to verify the high level logic or do you think that would be too much to do for each PR? Also, do we want to run all these

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

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

That used to be the case (and it is still the default QEMU behavior, if broadcast SMI is not negotiated). However, OVMF does negotiate broadcast SMI whenever QEMU offers the feature. Broadcast SMI is

That helps. Thanks for the quote! Sounds like a great idea. I believe this this change may not be cross-compatible between QEMU and OVMF. OVMF platform code would have to hide the stolen part of the

Laszlo Ersek <lersek@...> wrote: from SDM vol 3: " 34.5.1 Initial SMM Execution Environment After saving the current context of the processor, the processor initializes its core registers to

The TSEG base calculation is not trivial in this environment. The 32-bit RAM size needs to be read from the CMOS (IO port accesses). Then the extended TSEG size (if any) needs to be detected from PCI

"Yao, Jiewen" <jiewen.yao@...> wrote: Here are some ideas I have on the topic. *) In light of using dedicated SMRAM at 30000 with pre-configured relocation vector for initial relocation which

Laszlo Ersek <lersek@...> wrote: Do we need anything complex in relocation handler, though? From what I'd imagine, minimum handler should 1: get address of TSEG, possibly read it from

OK, I then misunderstood the purpose of this demo. I thought you were not supposed to be able to read it from either location in non-SMM mode. Thanks for the explanation. -boris

Boris Ostrovsky <boris.ostrovsky@...> wrote: ^^^ reads using 0x30000 base in non-SMM mode ^^^ reads from SMRAM temporarily aliased at 0xa0000 in non-SMM mode ^^^ reads using 0x30000 base in

"without a stack" looks very risky to me. Even if we manage to implement the guest code initially, we'll be trapped without a stack, should we ever need to add more complex stuff there. I expressed

It would be great if you could check. If real hardware does it at the chipset level, we will probably use Igor's suggestion of aliasing A-seg to 3000:0000. Before starting the new CPU, the SMI

Actually there is also an SMBASE MSR, even though in current silicon it's read-only and its use is theoretically limited to SMM-transfer monitors. If that MSR could be made accessible somehow outside

I give my thought. Paolo may add more.

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

(1) Sorry, my _DMA quote was a detour from QEMU -- I wondered how a physical machine with actual RAM at 0x30000, and also chipset level protection against DMA to/from that RAM range, would expose the

Thank you Mike! That is good reference on the real hardware behavior. (Glad it is public.) For threat model, the unique part in virtual environment is temp RAM. The temp RAM in real platform is per

Paolo, I find the following links related to the discussions here along with one example feature called