Warnings observed on the hosts :
zcat boot.gz | grep -i "Bad shared memory signature"
2024-07-26T09:25:17.144Z cpu0:2097152)WARNING: VMKAcpi: 332: PCC 0 : Bad shared memory signature 0x50434301
less vmkernel.log | grep -i "Bad shared memory signature"
2024-07-26T09:15:10.144Z Wa(180) vmkwarning: cpu0:2097152)WARNING: VMKAcpi: 332: PCC 0 : Bad shared memory signature 0x50434301 (expected 0x50434300)
2024-07-26T09:25:17.144Z Wa(180) vmkwarning: cpu0:2097152)WARNING: VMKAcpi: 332: PCC 0 : Bad shared memory signature 0x50434301 (expected 0x50434300)
vmware -vl
VMware ESXi 8.0.2 build-23825572
VMware ESXi 8.0 Update 2
VMware vSphere ESXi 8
This is a firmware bug.
The "Generic Communications Channel Shared Memory Region" (https://uefi.org/specs/ACPI/6.5/14_Platform_Communications_Channel.html#generic-communications-channel-shared-memory-region) signature is supposed to contain the value 0x504343nn where <nn> is the subspace ID. The subspace ID is derived from the index of the subspace definition in the PCCT, starting with index 0.
In the AML dump, we can see only a single PCC Subspace structure defined, making it subspace ID 0:
[030h 0048 001h] Subtable Type : 00 [Generic Communications Subspace]
[031h 0049 001h] Length : 3E
[032h 0050 006h] Reserved : 000000000000
[038h 0056 008h] Base Address : 000000006EB69020
[040h 0064 008h] Address Length : 0000000000001F38
[048h 0072 00Ch] Doorbell Register : [Generic Address Structure]
[048h 0072 001h] Space ID : 01 [SystemIO]
[049h 0073 001h] Bit Width : 08
[04Ah 0074 001h] Bit Offset : 00
[04Bh 0075 001h] Encoded Access Width : 01 [Byte Access:8]
[04Ch 0076 008h] Address : 00000000000000B2
[054h 0084 008h] Preserve Mask : 0000000000000000
[05Ch 0092 008h] Write Mask : 00000000000000FD
[064h 0100 004h] Command Latency : 000001F4
[068h 0104 004h] Maximum Access Rate : 00000000
[06Ch 0108 002h] Minimum Turnaround Time : 07D0
Based on the signature rules above, the 4 byte signature at 0x000000006EB69020 should be 0x50434300 but the platform controller or BMC has written 0x50434301 there instead.
Suggest customer to contact their OEM to fix their firmware.
We have a few alternate options:
1) Ask the OEM to fix their firmware.
2) Relax restrictions, only look at the first 3 bytes of the signature.
3) Relax restrictions, don't look at the signature at all.
4) PCC code could write the expected value to this address.
As far as this platform is concerned, unless there's some code on the x86 side using PCC today, this won't cause any issues.