Liming, All the three types will be introduced. By the way, fix one typo 'F4' for VT400 map key should be 'ESC [ 1 4 ~'. Thanks, Zhichao Sent: Friday, September 6, 2019 3:51 PM To: Gao, Zhichao

Zhichao: One clarification. What terminal type will be introduced? Xterm, VT400 and Linux? Thanks Liming Sent: Friday, September 06, 2019 12:56 PM To: rfc@edk2.groups.io Cc: devel@edk2.groups.io;

Hi everyone, Putty is a popular terminal console software in windows and it support various types of terminal keyboard type. I would like to add most of the type support. Here is the key map info.

lpc already has SMI negotiation feature, extend it by adding optin ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT to supported features. Writing this bit into "etc/smi/requested-features" fw_cfg file, tells QEMU

Laszlo Ersek <lersek@...> wrote: I guess we at point where patch is better then words, I'll send one as reply here shortly. I've just implemented subset of above (opened, closed+locked). I

I think TSEG-like behavior is between these two. That is, I believe we should have explicit open/close/lock operations. And, when the range is closed (meaning, closed+unlocked, or closed+locked), then

In other projects I've worked on, patch owners initiate the pre-commit build/test, and either comment on the review (ideally with link to the results) about its status, or have the CI system comment

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