Hello,

I would like to ask, when building firmware with EDK2 for real HW(but my question is either for an qemu-emulation).
Is there any relation of what number we write to the 0xB2 IO-port? In all the cases the call to SmiManage() with NULL
arguments is called, so should anyone expect different behavior regarding the value written on the IOport(0xb2) when triggering
the System Management Interruption?

Thanks

On 06/06/20 02:16, mzktsn@... wrote:

Hello,

I would like to ask, when building firmware with EDK2 for real HW(but my question is either for an qemu-emulation).
Is there any relation of what number we write to the 0xB2 IO-port?

For a relation to exist, it needs to be between multiple things (at
least two).

Above, you mention one thing only (a "number we write to the 0xB2 IO-port").

What is the *other* thing to which you want to relate the value written
to 0xB2?

In all the cases the call to SmiManage() with NULL
arguments is called,

Yes, root SMI handlers are processed every time.

so should anyone expect different behavior regarding the value written on the IOport(0xb2) when triggering
the System Management Interruption?

The effects of writing any particular command value to IO port 0xB2 are
entirely platform specific. On some platforms, it's not even IO port
0xB2 that triggers an SMI.

Two example commits:

* 17efae27acaf ("OvmfPkg/CpuHotplugSmm: introduce skeleton for CPU
Hotplug SMM driver", 2020-03-04)

This shows that value 4 for signaling a VCPU hotplug is a platform *choice*.

* 6e3c834ae47d ("SecurityPkg Tcg: Use SW SMI IO port PCD in Tpm.asl",
2020-04-21)

This shows that some platforms use an IO port different from 0xB2 for
triggering an SMI.

Thanks
Laszlo

Thanks a lot.