[Bug 248514] jedec_dimm(4) and imcsmb(4): support of memory controllers in Skylake and newer Intel CPUs

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248514

--- Comment #10 from Ravi Pokala <rpokala at panasas.com> ---
Sorry, this fell off my radar.

The problem here is that the iMC-SMBus controller was not really intended for
use by the OS. During POST, the memory controller uses it to read the SPD
information from the DIMMs and configure itself to use their DRAM; during
normal operation, the system firmware (the Management Engine?) uses it to read
the TSOD temperature from the DIMMs. The hardware has a BUSY indicator, but it
appears to be advisory, and it's possible that firmware does not honor it,
which could allow firmware-initiated operations to stomp on OS-initiated
operations.

And to top it off, I know Intel board firmware disabled OS access to the
iMC-SMBus controllers on *Well outright, as part of their security-hardening
fixes after Spectre-Meltdown; I suspect other board vendors followed suit. It's
possible that for *Lake, they disabled it from the start.

The upshot of all this, is that the controller might not be usable by the OS on
*Lake CPUs.

Try adding this line near the start of imcsmb_transfer():

================================================================
        orig_cntl_val = pci_read_config(sc->imcsmb_pci,
            sc->regs->smb_cntl, 4);
+       device_printf(sc->dev, "cntl: 0x%08x\n", orig_cntl_val);
        cntl_val = orig_cntl_val;
================================================================

I'm particularly interested in bit 26 (0x04000000), SMB_DIS_WRT; if it is set,
the BIOS has locked the OS out from using the iMC-SMBus controller, and that's
game over. :-/

While I appreciate your offer of remote access, I don't have any time to dig
into this right now, and probably won't any time in the next few months.

-- 
You are receiving this mail because:
You are the assignee for the bug.