Feature: Read offsets / confirm applying worked about undervolt

[davidr]

Absolutely no apologies necessary. This was exceptionally helpful, and I'll work out the rest. Again, many many thanks for this work.

[davidr]

Out of curiosity, how did you come by the logic to do this? This stuff obviously isn't documented super well, and I'm trying to follow along in unpack_offset() and unconvert_rounded_offset(), and there's deep mojo there I don't understand, particularly:

in unpack_offset():

plane_index = int(msr_response / (1 << 40))
return unconvert_offset(msr_response ^ (plane_index << 40))

I haven't looked super hard, but I've yet to run into a situation where plane_index is anything other than 0 for any call of read_offset(). In your sample code, you unpack a value of "0x40000000000", so maybe your CPUs are just returning something in those 40:36 bits that mine aren't? No matter what plane I write to the MSR mailbox and then read, those bits are zeroed for me, even though the read will return the correct offset. (I'm testing on i7-8650U)

and in unconvert_rounded_offset():

return x if x <= 1024 else - (2048 - x)

I'm not sure I understand why this is necessary.

At any rate, there's so little information on this available, your code is astonishingly helpful to everyone looking. Thank you so much for all your work!

[georgewhewell]

@davidr Most of the information was gathered from this repo, which in turn collected information from this thread.

re: unpack_offset- it was reported in #9 that CPUs earlier than Gen 5 include the plane index in the returned value, so it must be stripped before converting back to voltage. I confirmed this on older machine, although on a modern machine I see the same results as you.

re: unconvert_rounded_offset- I forget why this is necessary. If you change this to just return y >> 21, tests will fail like so:

File "/home/grw/src/undervolt/undervolt.py", line 90, in undervolt.unconvert_offset
Failed example:
    unconvert_offset(0xf0000000)
Expected:
    -125.0
Got:
    1875.0

So it seems to be because the return value is in the domain [0-2048], but we want [-1024, 1024]. Sorry I can't explain more!

[sesam]

The adjustment only for numbers with the high bit set, leaving small ints alone, looks like parsing for a 10 bit signed integer. 2^10 is 1024.