I have a problem using wrmsr IA32_PERF_CTL, in kernel space I get a STATUS_PRIVILEGED_INSTRUCTION exception and Windbg, which has a wrmsr function, reports "no such msr". This is on an i5-2410M CPU.
The same code and Windbg do not generate errors on another test platform. What could be the cause of this?
By the way rdmsr IA32_PERF_STS works OK on both platforms.
Can you access other MSR registers from within Windbg?STATUS_PRIVILEDGED_INSTRUCTION exception should not be returned unless your code is not executing in ring0.Can you issue an breakpoint on 0x199 MSR access?There is also a possibility to debug debugger.I do not know if this can be achieved with kernel mode debugger but this is very often done with the user mode debugger with the command .dbgdbg.
Yes, the rdmsr 198 call works, both in my code and in windbg. I havent tried writing to any other MSRs with windbg, but it is an interesting suggestion.
This code is in a driver and thus is running at ring0, and dont forget on a different CPU (32 bit) it workes perfectly OK,
As for debugging the exception is thrown when the instruction wrmsr is run, and as stated the exception thrown is STATUS_PRIVILEGED_INSTRUCTION.
I was really hoping someone from Intel could enlighten me on this. (By the wa the XPSS method fails to evaluate even though it enumertes as a child and _PCT does not return 64 bit address size which indicates to me that XPSS is not supported. Could someone verify that?)
No, the driver is not signed, but it is installed because I turned of driver signing checking. And yes, I am triggering the exception form within an asembly language fundtion in my driver code. Analysing in windbg shows the exception to have occured at wrmsr, which is what I stated in my original post.
I do note though that enum children and evaluate methods does return SPSS Package data. Does this mean that power management is controled through the values returned in these structures and the method via IO? Any Intel experts here who can answer?
> STATUS_PRIVILEDGED_INSTRUCTION is a hardware generated exception which is handled by the OS.
Well on win 7 I get an exception, ie BSOD. I can exception handle it in the driver and get the exception code, which is better, but I would like to know why it throws an exception.
>It is very strange behaviour because you are able to access other MSR registers from within the same code
Only with a rdmsr 0x198, I havent tried writing any other MSRs , I dont want to mess the chip up since these are powerfull commands.
>Can you post the call stack
Well it is litterally:
WrMsr64 <-- my driver func with assembler in it
wrmsr <-- exception happens here
>source of the exception could be a processor itself.
Deffinitely. It IS the CPU causing it.
>This instruction must be executed at privilege level 0
I am calling wrmsr from a kernel mode driver so it is at ring 0. Dont forget this code works perfectly OK on another platform.
In respect of "Specifying a reserved or unimplemented MSR address in ECX will also cause a
general protection exception" the thing is that ACPI _PSS says to use Functionally Fixed Hardware as the mode to control CPU power, which means using the IA32_PERF_CTL MSR in wrmsr.
Perhaps there is a bug in ACPI.sys that is returning an incorrect access method for this particular CPU.
Because my driver is a lower filter to the CPU driver thus it sits above the APCI.sys PDO. It uses the ENUM_CHILDREN and EVALUATE_METHOD IOCTLs to get ACPI information. In this case _PCT and _PSS indicate that CPU power is controled via FFHW, ie, the IA32_PERF_CTL register.
Thanks for providing clearer picture of the driver's environment.
Afaik for debugging ACPI.sys(If you are interested in it) driver there is need to instal checked build version of that driver.
Can you create simple driver not to be bound to some driver stack and try to access 0x199 MSR?
In fact the device object wrmsr is called from is not on the PDO enumerated by ACPI.sys (there are two device objects in the driver, one is the filter, the other provides a symbolic link so an application can communicate with the driver).
I have discovered that if edx is set to zero the exception does not occur.
Of course doing so is contrary to all that I have read where the usual procedure would be to do a rdmsr 198h, then change eax to the required value follwed by wrmsr 199h.