Laszlo Ersek <lersek@...> wrote: theoretically depending on argument in 0xb3, it should be possible to rise directed SMI even if broadcast ones are negotiated. if I'd sum it up: (01) On boot

Laszlo Ersek <lersek@...> wrote: Ok, let me check if we could cannibalize q35 pci-host for the task or it would be easier to extend MMIO cpu-hotplug interface. I'll probably come back with

Hi Sean, These tests sound awesome! commits. I'd like to keep the per-PR tests down to 10 minutes. On the other hand, it would be great if all of these tests could be performed daily or

Yes. The maintainer will prepare a local branch that is rebased to master, and has all the mailing list feedback tags (Reviewed-by, etc) applied. The maintainer also does all the local testing that

Mike: I add my comments.

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