Laszlo Ersek <lersek@...> wrote: yep, I'm looking at it from theoretical perspective so far, but what could be done in reality might be limited. it could be stolen RAM + black hole like

Laszlo Ersek <lersek@...> wrote: currently there is no SMRAM at 0x30000, so all access falls through into RAM address space and we are about to change that. but firmware doesn't have to use

I'll let Mike respond. Thanks Laszlo

I'm sure you are *technically* right, but you seem to be assuming that I can modify or rearrange anything I want in edk2. :) If we can solve the above in OVMF platform code, that's great. If

Laszlo/Mike, The idea that the maintainer must create the PR is fighting the optimized github PR flow. Github and PRs process is optimized for letting everyone contribute from "their" fork while

I believe this can work if: - the submitter has a github account - the maintainer knows the submitter's account name - the maintainer manually subscribes the submitter to the PR (I have never tried

I don't see this as a huge change, relative to the current process. Before, it's always been up to the subsys maintainer to apply & rebase the patches locally, pick up the feedback tags, and run at

Can someone draw a flow chart of who does what to help clarify? It sounds like maintainers are going to be the very important bridges between CI system and the patch owners (developers). Important it

This sounds convincing enough, for the hotplugged CPU; thanks. So now my concern is with step (01). While preparing for the initial relocation (of cold-plugged CPUs), the code assumes the memory at

Laszlo Ersek <lersek@...> wrote: It sure can but this way it won't get access to privileged SMRAM so OS can't subvert firmware. The next time SMI broadcast is sent the CPU will use SMI handler

Sorry, I was thinking the evaluation I was doing was having the entire CI run in Jenkins, not only the boot testing. I don't have the array of hardware you'd want for boot testing, just mostly large

In step (03), it is the OS that handles the SCI; it transfers control to ACPI. The AML can write to IO port 0xB2 only because the OS allows it. If the OS decides to omit that step, and sends an

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