Oh, I'm not trying for an os unlock just yet. I'm thinking that somehow, your chip had its switch flipped. I don't know where that switch is yet, or what it is, although if I was Intel, I would put it in an undocumented msr. Basically, your chip proves that the extra core logic that allows for Hyper-Threading is not physically removed (not that i expected it to be). That's the only major assumption I'm working with at the moment. And, it's a pretty safe one at this point.
What I have managed to do so far is examine the MADT of my own i5 chip. Now, here's what I found. The physical id's of the individual enabled cores are not sequential (This may be true of all i5's. Feel free to try this one at home. Fire up aida64, look at "ACPI" then "apic" or "madt"). 0, 2, 4, and 6 exist (only 4 ids), but the chip -reserves- 8 apic id's. This can be verified using the documented return values of the cpuid instruction, and comparing it to the raw values actually returned from the chip, and then comparing it to a dump of the ACPI tables.
I did another thing. I did some research, and found out that the memory address of the lapic (the local advanced programmable interrupt controller, ie: the part of the cpu that lets it communicate with other cpus and the chipset) of the bsp, or bootstrap processor (the one that executes all bios code) exists at address 0xfee00000 in memory. the icr (interrupt command register) exists with an offset of 0x300 from that location. The target of the icr can be set at 0x10 from there. This means that i can manually set a target, and manually fire an interrupt at that target, by poking those registers.
I executed the mm command to set the memory address 0xfee003010 to 0x01. this sets the target of the lapic to the physical address where the first deactivated hyperthreaded core should be. I then set memory address 0xfee00300 to 00 00 05 00. This is the "INIT IPI" Or in layman's terms, the command to start up. I then set it to 00 00 06 00. This is the command to start executing whatever is in its stack. Of course, nothing happened because the uefi firmware never gave it a stack, or anything to execute other than a loop full of nops. I tried it on the physical cpu's that were already initialized, and it did nothing [although the system worked flawlessly in the uefi shell (which is verified to use only one core), when an os tried to boot, it would go to turn on the cores that it knows are there, and are supposed to be doing absolutely nothing, find them executing already, and then freak out and kernel panic]. I tried it once more, with the address set to the bsp (0x00) and the system crashed. hard. So, it's entirely possible that the firmware explicitly disabled the interrupts on the lapic of the disabled cpus. Of course, that's going to bring me to my next point in a minute. I think it's more likely that it just had nothing to do at that point, didn't own any memory because the firmware already gave it to either the bsp or the other aps. AND basically nothing even knows that core exists, so it makes sense that kicking it on manually would do nothing to affect anything else. See in this case nothing is something, because if that was an invalid/remapped/random address, the system would have complained. Loudly. Instead, I got a fat load of nothing. See, on an i5 that says it only has 4 units, how can the firmware know that there are more? Answer: it can't. Not without probing them, and you DON'T probe the cpu like that. not even in firmware. The chance for something to go wrong, and corrupt all manner of things is very, very high. Much better to just identify the cpu using "cpuid" and set up everything around what it tells you.
So this brings me to where we stand right now. I'm 90% sure that i've -already- managed to kick on all 8 cpus of my i5. (By editing MMIO values of the BSP's LAPIC's ICR. By HAND) However, I have no way to verify that the cpus are executing without making them do something meaningful, which of course is not really possible in an OS which doesn't know or care they exist, or from a single threaded environment where the only thing i can really do is edit the BSP's local memory by hand. So, i'm going to have to do this a different way. My idea to force on the HT is to edit the uefi bios so that it reads an i5 as if it were an i7.
In order to do that, I set out to disassemble the routines in the uefi one at a time. And it's then that i discovered something very.. very.. interesting. According to the pei and dxe specs, most of the code in the pei and dxe routines are just functions that other routines can access and use. and when ripping them apart, i found a whole lot of that, but i didn't find the main routine that actually identifies and initializes the cpu's. I found many instructions for making the BSP do something and not really a whole lot concerning the AP's outside of the acpi table generator, which doesn't seem to do a lot of generating. I mean, I'm sure it does, but because of how pei and dxe work, there's not a lot of real code. just function calls. pei and dxe drivers... they're more like dll's and less like exe's, and very difficult to decipher.
What i DID find though was in the last place i looked, and the first place the cpu looks. The "Security Core". The very first piece of code to touch the cpu, which begins it's execution in real mode, and within 20 instructions or so, jumps into "protected mode" which allows for super fast boot times, fancy uefi shells, and... the ability to let me spot the protected-mode entry point in like 2 minutes. So, that means that the exact real-mode entry point, the first instruction to reach the cpu, should be very close. What this is going to do is let me know what the EXACT state of the processor's registers are at all times during execution. all of them. The stack, local memory, cache, absolute location of function calls and variables, everything! If i can follow the execution line by line (There's only a thousand, and the cpu has zero access to any ram at this point), and find out where it asks how many logical cpu's there are, I can adjust the offest by shl 0x1, to turn the "i have four" into an "i have eight". Then at that point the bios will do all the work for me! (unless the CPUs are physically disabled, which we know they aren't).
This is really playing with fire. It's analogous to poking your hypothalamus with a stick. if I make an edit and mess it up, I will truly brick a board beyond recovery. I may order some extra bios chips just in case.
For all you out there who can follow this post, I would appreciate some feedback, or especially some assistance if anyone has the uefi hacking skills to help me get this done.
Facebook
Twitter