Patch Set 3:

Patch Set 3: Code-Review+1

I tried again, I ended up with the same problem. I think I found out why, though.

In `src/cpu/x86/mp_init.c`, function `smm_do_relocation`, there's a calculation that needs to match that of the SMM module loader. In my case, it didn't, and that's why I was getting hangs whenever SMM was called. Adding this offset worked for me on Haswell (but it's not a good idea to hardcode it):

 perm_smbase += (0x7faea000 - 0x7f800000);

The first value is the location of the relocated SMBASE for CPU #0. The second value is smram_start.

Angel,
I completely understand the problem you are having. Yes, you are right. In mp_init.c, there is some code that is needed. Here is what I have in my mp_init.c, it was in my original patch but not in loader version 2, hence why are you seeing the problems. The code below needs to go in smm_do_relocation.

	/*
	 * The permanent handler runs with all cpus concurrently. Get the location
	 * of the SMBASE for this CPU since the loader already created a map of all
	 * CPU threads and where each entry point will reside in the SMRAM region
	 */
	perm_smbase = smm_get_cpu_smbase(cpu);
	mp_state.perm_smbase = perm_smbase;
	if (perm_smbase <= 0) {
		printk(BIOS_ERR, "%s : error, smbase 0x%x not found for this cpu 0x%x\n",
		__func__, (int)perm_smbase, cpu);
		return;
	}
	mp_state.ops.relocation_handler(cpu, curr_smbase, perm_smbase);

So I will add this snippet into mp_init.c and update this patch if you agree.

Sure. You can also grab what I've done on CB:44174 which would work for both smm module loaders. Also, David and I left some comments on other patchsets, which would be good to take care of as well.

View Change

To view, visit change 43684. To unsubscribe, or for help writing mail filters, visit settings.