SMM on K8

[Stefan Reinauer]

First shot, untested

[Rudolf Marek]

Hi all,

Here is a SMM patch that actually works on VT8237S! It supports only SMI CMD so 
sending something to port 0x52f should trigger it.

It is mostly in good state however following needs to be done. Thats left to 
Tobias or Fengwei.

0) only enabled board is m2v-mx se (trivial to enable others VIA 8237 based)
1) PCIe access is hardcoded to 0xe000000

This sucks,but generally mmconfig is good idea beacuse it does not create races...

So what about that?

a) change the SMM handler to save PCIcfg/PCIdata??? regs
b) make MMCONFIG static to 0xe00000
c) some clever way to get idea where it is without PCI access

2) Dualcore/more cpus

I hardcoded that for single CPU. You need most likely change model_fxx_init.c 
and call smm_init from there (except that copy can done via CPU)

All CPUs needs to set Aseg ENable and SMM_BASE (to different address)

No smm_relocate.S is used because we dont need it on AMD, we have the MSRs...

3) More features to SMM

Handy would be ACPI enable/disable -maybe whats there will work
and Poweroff if powerbutton is pressed and acpi does not work yet ;)

Otherwise SMM is not used at all so we don't really need any features...

4) Cool stuff

Emulate some hardware one can do traps for IO and for MMIO so any HW can be 
created just for fun (TPM ;)

5) remove HACK_SMM
The header file dislikes the include someone needs to fix that.

6) SMM locking

The SMM should be locked, there is even a register for that. However I dont know 
if all CPUs needs to lock... and if some cpu is locked, can others still access 
the memory (for the memcopy?)

Also we lock SMM on the base in the RAM, we should create a dummy "RSM" like 
handler if we don't have any SMI handler on K8.

Thanks goes to Stepan for initial version (from mine POC version).

Thanks,
Rudolf

[Marc Jones]

2010/11/17 Rudolf Marek :
> Hi all,
>
> Here is a SMM patch that actually works on VT8237S! It supports only SMI CMD
> so sending something to port 0x52f should trigger it.
>
> It is mostly in good state however following needs to be done. Thats left to
> Tobias or Fengwei.
> only enabled board is m2v-mx se (trivial to enable others VIA 8237 based)
> PCIe access is hardcoded to 0xe000000
>
> This sucks,but generally mmconfig is good idea beacuse it does not create
> races...
>
> So what about that?
>
> a) change the SMM handler to save PCIcfg/PCIdata??? regs
> b) make MMCONFIG static to 0xe00000
> c) some clever way to get idea where it is without PCI access
> Dualcore/more cpus
>
> I hardcoded that for single CPU. You need most likely change
> model_fxx_init.c and call smm_init from there (except that copy can done via
> CPU)
>
> All CPUs needs to set Aseg ENable and SMM_BASE (to different address)
>
> No smm_relocate.S is used because we dont need it on AMD, we have the
> MSRs...
> More features to SMM
>
> Handy would be ACPI enable/disable -maybe whats there will work
> and Poweroff if powerbutton is pressed and acpi does not work yet ;)
>
> Otherwise SMM is not used at all so we don't really need any features...
> Cool stuff
>
> Emulate some hardware one can do traps for IO and for MMIO so any HW can be
> created just for fun (TPM ;)
> remove HACK_SMM
>
> The header file dislikes the include someone needs to fix that.
> SMM locking
>
> The SMM should be locked, there is even a register for that. However I dont
> know if all CPUs needs to lock... and if some cpu is locked, can others
> still access the memory (for the memcopy?)
>
> Also we lock SMM on the base in the RAM, we should create a dummy "RSM" like
> handler if we don't have any SMI handler on K8.
>
> Thanks goes to Stepan for initial version (from mine POC version).

I haven't looked at the patch, but this is exciting development. Open
SMM implementation should interest many people.

Marc