TECK

macrumors 6502a
Original poster
Nov 18, 2011
705
216
I need your help to understand how the Data values are set into OpenCore configuration. Looking at documentation for Cpuid1Data:
7.5 Emulate Properties
  1. Cpuid1Data
    Type: plist data, 16 bytes
    Failsafe: All zero
    Description: Sequence of EAX, EBX, ECX, EDX values to replace CPUID (1) call in XNU kernel.
    This property serves for two needs:
    • Enabling support of an unsupported CPU model.
    • Enabling XCPM support for an unsupported CPU variant.
    Normally it is only the value of EAX that needs to be taken care of, since it represents the full CPUID. The remaining bytes are to be left as zeroes. Byte order is Little Endian, so for example, A9 06 03 00 stands for CPUID 0x0306A9 (Ivy Bridge).
    For XCPM support it is recommended to use the following combinations.
    • Haswell-E (0x306F2) to Haswell (0x0306C3):
    Cpuid1Data: C3 06 03 00 00 00 00 00 00 00 00 00 00 00 00 00 Cpuid1Mask: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00
    • Broadwell-E (0x0406F1) to Broadwell (0x0306D4):
    Cpuid1Data: D4 06 03 00 00 00 00 00 00 00 00 00 00 00 00 00 Cpuid1Mask: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00
    Further explanations can be found at acidanthera/bugtracker#365. See Special NOTES for Haswell+ low-end.

How did @cdf ended with AAAAAAAAAAAAAACAAAAAAA== and AAAAAAAAAAAAAACAAAAAAA== values? 16 bytes means C3 06 03 00 00 00 00 00 00 00 00 00 00 00 00 00, for example. If I convert this to base64, I get gibberish.

Here it is an easier example, UIScale can have either 01 or 02 values, but when I convert 02 to Base64, I get:
Code:
$ echo -n '02' | base64
MDI=

instead of Ag==. Thank you for teaching an OC newbie.
 
Last edited:

cdf

macrumors 65816
Jul 27, 2012
1,403
1,307
I'll answer the easier question first. You want to convert the hex value: printf "\x02" | base64.

For the other question, try printf "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00" | base64. Taking endianness into account, the 00 00 00 80 part corresponds to the ECX register holding a binary value of 10...0 (31 zeroes). That single 1 is the VMM flag bit.
 
  • Like
Reactions: TECK
Comment

dataid

macrumors member
Feb 1, 2020
70
38
USA
I need your help to understand how the Data values are set into OpenCore configuration. Looking at documentation for Cpuid1Data:


How did @cdf ended with AAAAAAAAAAAAAACAAAAAAA== and AAAAAAAAAAAAAACAAAAAAA== values? 16 bytes means C3 06 03 00 00 00 00 00 00 00 00 00 00 00 00 00, for example. If I convert this to base64, I get gibberish.

Here it is an easier example, UIScale can have either 01 or 02 values, but when I convert 02 to Base64, I get:
Code:
$ echo -n '02' | base64
MDI=

instead of Ag==. Thank you for teaching an OC newbie.

Check out this Lifewire article: How Base64 Encoding Works
for an explanation of why Base64 is used, the encoding logic with conversion examples, the coding table and the use of the Base64 padding character the Equal sign (=).
 
  • Like
Reactions: TECK
Comment

h9826790

macrumors P6
Apr 3, 2014
15,235
7,533
Hong Kong
I need your help to understand how the Data values are set into OpenCore configuration. Looking at documentation for Cpuid1Data:


How did @cdf ended with AAAAAAAAAAAAAACAAAAAAA== and AAAAAAAAAAAAAACAAAAAAA== values? 16 bytes means C3 06 03 00 00 00 00 00 00 00 00 00 00 00 00 00, for example. If I convert this to base64, I get gibberish.

Here it is an easier example, UIScale can have either 01 or 02 values, but when I convert 02 to Base64, I get:
Code:
$ echo -n '02' | base64
MDI=

instead of Ag==. Thank you for teaching an OC newbie.
Not really answering your question. But for info, Hackintool can do all the conversions we usually need.
Screenshot 2020-05-15 at 5.23.12 PM.png

Screenshot 2020-05-15 at 5.23.34 PM.png


Screenshot 2020-05-15 at 5.27.05 PM.png


Screenshot 2020-05-15 at 5.28.24 PM.png
 
  • Like
Reactions: TECK
Comment

TECK

macrumors 6502a
Original poster
Nov 18, 2011
705
216
You guys are amazing, thank you!

The 00 00 00 80 part corresponds to the ECX register holding a binary value of 10...0 (31 zeroes). That single 1 is the VMM flag bit.
This makes a lot of sense now, thank you.

Next, the GPU DeviceProperty:
Code:
            <key>PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)</key>
            <dict>
                <key>agdpmod</key>
                <data>cGlrZXJhAA==</data>
                <key>rebuild-device-tree</key>
                <data>AA==</data>
                <key>shikigva</key>
                <data>UA==</data>
            </dict>

I'm looking at Whatevergreen documentation and:
- agdpmod is set to pikera, default for external GPUs OK
- rebuild-device-tree is a new property not yet documented, I don't know what values to use, why 00?
- shikigva has a proposed chart but does not not match @cdf choice, why 50?


Off-topic, related to Data manipulation:
One interesting detail, Hackintool does not support the character constant \0. At least, I do not know how to paste it or enable it. If you know how to do it, please let me know. Otherwise, is safe to stick with the good old terminal.

In C programming:
The character constant '\0' represents the character with value zero, the null character. '\0' is often written instead of 0 to emphasize the character nature of some expression, but the numeric value is just 0.

@h9826790 if I enter ASCII pikera into Hackintool, I get a different Base64 value. If I use Apple's library plistlib, I need to pass the correct Data, otherwise I will get an invalid Base64 value.

These would be the correct values:
Code:
device_properties = {
    'Add': {
        'PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)': {
            'agdpmod': Data('pikera\0'),
            'rebuild-device-tree': Data('00'),
            'shikigva': Data('50')
        }
    },
    'Block': {}
}

In other words, ASCII strings passed to Data should always end with a character constant '\0', while Hex values should be escaped with a '\x':
Code:
$ printf 'pikera\0' | base64
cGlrZXJhAA==

$ printf '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00' | base64
AAAAAAAAAAAAAACAAAAAAA==

If I paste the Base64 value, it will show ASCII pikera with a hidden character at the end (the character constant '\0'):

Screen Shot 2020-05-15 at 9.27.17 AM.png


Code:
$ printf 'pikera\0' | base64
cGlrZXJhAA==

If I press delete once at end of ASCII pikera field, cGlrZXJhAA== will turn cGlrZXJh and Hex 70 69 6B 65 72 61 00 will turn 70 69 6B 65 72 61. It is missing a 00, which is the character constant '\0'.

Screen Shot 2020-05-15 at 9.18.46 AM.png


Code:
$ printf 'pikera' | base64
cGlrZXJh

Now that I understand how to manipulate transformations, let's focus on the learning. :D
 
Last edited:
Comment

startergo

macrumors 68040
Sep 20, 2018
3,517
1,555
Use the VMM flag as an example.

I presume you were more or less asking the same thing here:
Correct. I saw this as well:
Lets continue in this thread I think it is more appropriate
@cdf
For bit 20, I believe you would set Cpuid1 to AAAAAAAAAAAAAAgAAAAAAA==
So I see SSE4_2 (EAX=01h, ECH=0):ECX[20]
1604318407401.png

And for XSAVE XSAVEC XSAVEOPT we have:
1604318519462.png

So the CPUID1 would be what?
 
Comment

Dayo

macrumors 65816
Dec 21, 2018
1,168
571
I get the same feature set with "AAAAAAAAAAAAAAgAAAAAAA==" as before.

Code:
FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS
HTT TM PBE SSE3 DTES64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1

PS: I set the same thing for mask and data. Not sure if relevant.
 
Comment

startergo

macrumors 68040
Sep 20, 2018
3,517
1,555
I get the same feature set with "AAAAAAAAAAAAAAgAAAAAAA==" as before.

Code:
FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS
HTT TM PBE SSE3 DTES64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1

PS: I set the same thing for mask and data. Not sure if relevant.
I am not sure but bit 20 should be maybe this:
AAAAAAAAAAAACAAAAAAAAA==
in Hex: 0x00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00
Reversed hex: 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00
1604321097283.png

which is AAAAAAAAAAAACAAAAAAAAA==. That looks like bit 52 isn't it?
 
Last edited:
Comment

startergo

macrumors 68040
Sep 20, 2018
3,517
1,555
@cdf so printf "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00" | base64 is
AAAAAAAAAAAAAAgAAAAAAA==
How is that refering to bit 20?
printf "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00" | base64 is
AAAAAAAAAAAAAAAAAAgAAA==
Hex 80000 is Binary 00000000000010000000000000000000
 
Last edited:
Comment

Syncretic

macrumors regular
Apr 22, 2019
183
413
Be careful with setting the XSAVE/XSAVEC/XSAVEOPT bits on an MP3,1 (or MP4,1/5,1). Those can cause the kernel to decide it needs to preserve the AVX registers (YMM/ZMM) across context switches, and it will try to use the XSAVE/XSAVES/XSAVEC/XSAVEOPT/XSETBV/XGETBV/XRSTOR/XRSTORS instructions. None of those registers or instructions are present on MP3,1 (or MP4,1/MP5,1), and since the attempt to use them is in the kernel, you're basically guaranteeing a kernel panic.

(n.b. I haven't looked under the hood of OC, so I don't know what sort of capture/emulation it might be doing; it might handle this already. I do know firsthand that tinkering with XSAVE* can open a can of worms. Caveat operandor.)
 
  • Like
Reactions: startergo
Comment

Dayo

macrumors 65816
Dec 21, 2018
1,168
571
Not AAAAAAAAAAAACAAAAAAAAA==. This adds SEGLIM64 to the feature set:
Code:
FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS
HTT TM PBE SSE3 DTES64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SEGLIM64
 
Comment

startergo

macrumors 68040
Sep 20, 2018
3,517
1,555
Be careful with setting the XSAVE/XSAVEC/XSAVEOPT bits on an MP3,1 (or MP4,1/5,1). Those can cause the kernel to decide it needs to preserve the AVX registers (YMM/ZMM) across context switches, and it will try to use the XSAVE/XSAVES/XSAVEC/XSAVEOPT/XSETBV/XGETBV/XRSTOR/XRSTORS instructions. None of those registers or instructions are present on MP3,1 (or MP4,1/MP5,1), and since the attempt to use them is in the kernel, you're basically guaranteeing a kernel panic.

(n.b. I haven't looked under the hood of OC, so I don't know what sort of capture/emulation it might be doing; it might handle this already. I do know firsthand that tinkering with XSAVE* can open a can of worms. Caveat operandor.)
Thanks for the explanation. I wanted to do some testing based on the latest Vmware CPU requirements.
Not AAAAAAAAAAAACAAAAAAAAA==. This adds SEGLIM64 to the feature set
Can you please run MacCPUID and see which bit is enabled in this section:
1604325232707.png
 
Comment

startergo

macrumors 68040
Sep 20, 2018
3,517
1,555
Be careful with setting the XSAVE/XSAVEC/XSAVEOPT bits on an MP3,1 (or MP4,1/5,1). Those can cause the kernel to decide it needs to preserve the AVX registers (YMM/ZMM) across context switches, and it will try to use the XSAVE/XSAVES/XSAVEC/XSAVEOPT/XSETBV/XGETBV/XRSTOR/XRSTORS instructions.
Well the good part is that I did not have kernel panic and XSAVE is "enabled" with
Code:
<key>Cpuid1Data</key>
            <data>
            AAAAAAAAAAAAAAAEAAAAAA==
            </data>
            <key>Cpuid1Mask</key>
            <data>
            AAAAAAAAAAAAAAAEAAAAAA==
            </data>
:
Code:
sysctl machdep.cpu.features
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 POPCNT AES PCID XSAVE

So here are the calculations:
Based on the Figure 3.7 above XSAVE is bit 26 in the ECX leaf. ECX leaf is the 3rd leaf:
Cpuid1Data: 00000000 00000000 00000004 00000000
EAX EBX ECX EDX
Cpuid1Mask: 00000000 00000000 00000004 00000000

Bit 26 enabled in HEX is 0x4000000 byte swapped is 00000004
1604332843560.png


MacCPUID does not report it though:
1604332994633.png
 
Last edited:
Comment

cdf

macrumors 65816
Jul 27, 2012
1,403
1,307
@cdf so printf "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00" | base64 is
AAAAAAAAAAAAAAgAAAAAAA==
How is that refering to bit 20?
printf "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00" | base64 is
AAAAAAAAAAAAAAAAAAgAAA==
Hex 80000 is Binary 00000000000010000000000000000000
I'm quite busy at the moment with other things. If it's still unresolved, I'll take a closer look later.
 
Comment

startergo

macrumors 68040
Sep 20, 2018
3,517
1,555
I'm quite busy at the moment with other things. If it's still unresolved, I'll take a closer look later.
I think I got it. See above. Not sure though why MacCPUID does not report the spoofing. There is another confusion for me when you have time please clarify. The manual states when spoofing EAX to set the CPUID1Mask to F when corresponding value is changed and for enabling bits we set both CPUID1DATA and CPUID1MASK to the same value.
 
Comment

startergo

macrumors 68040
Sep 20, 2018
3,517
1,555
I think it is actually AAAAAAAAAAAAABAAAAAAAA==
Code:
printf "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x00\x00\x00" | base64
AAAAAAAAAAAAABAAAAAAAA==
Bit 20:
1604335430721.png

@Syncretic Enabling AVX bit along the XSAVE bit leads to kernel panic on boot.
 
  • Like
Reactions: cdf
Comment

Dayo

macrumors 65816
Dec 21, 2018
1,168
571
I think it is actually AAAAAAAAAAAAABAAAAAAAA==
Of course it is:

Code:
FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS
HTT TM PBE SSE3 DTES64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2
Nice one!
 
  • Like
Reactions: cdf and startergo
Comment
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.