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.
Hi Matt
Try to access that MSR register by passing its address in ecx.Try to locate this MSR register address and access it with the help of windbg.
The address of IA_PERF_CTL is 0x199.Try to access this register by its address.
Obviously IA_PERF_CTRL is a define and has the value 0x199 and obviously this value is passed in ecx otherwise it wouldnt have worked on the other platform.
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?)
>>>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,>>>
Yes it is obvious.Is your driver signed?You mentioned that on 32-bit machine everything works fine.Because it is not obvious from your post I would like to ask you can you trigger the priviledged instruction exception from within your code.If it is possible you can with the help of kernel debugger walk the stack and locate the culprit.
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?
Thanks
>>>Analysing in windbg shows the exception to have occured at wrms>>>
STATUS_PRIVILEDGED_INSTRUCTION is a hardware generated exception which is handled by the OS.It is very strange behaviour because you are able to access other MSR registers from within the same code.It can point to the faulty or incorrect processor behaviour when the wrmsr is compared to the current priviledge level.Can you post the call stack?I was thinking about the disabling the handler if one exists in IDT for priviledged instruction exception,but it probably will not help because of source of the exception could be a processor itself.
> 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.
Matt, Did you look at
Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2 (2A, 2B & 2C):
Instruction Set Reference, A-Z ( Order Number: 325383-044US August 2012 )?
Here is a quote from Page 1043:
...
This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection
exception #GP(0) is generated. Specifying a reserved or unimplemented MSR address in ECX will also cause a
general protection exception. The processor will also generate a general protection exception if software attempts
to write to bits in a reserved MSR.
...
>>>Specifying a reserved or unimplemented MSR address in ECX will also cause a
general protection exception. The processor will also generate a general protection exception if software attempts
to write to bits in a reserved MSR.>>>
Very interesting information possibly could explain the priviledged instruction exception on that processor.
>>>Well on win 7 I get an exception, ie BSOD>>>
Can you search for installed exception handlers with the kernel mode command idt -a.
Hi Sergey
>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.
>>>Perhaps there is a bug in ACPI.sys that is returning an incorrect access method for this particular CPU>>>
Why ACPI.sys? your code is accessing directly MSR register.
>Why ACPI.sys?
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).
It seems that it is processor bug.Probably some of the flags in physical representation of the 0x199 MSR were set and thus trigerring general protection exception.
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.
Hi Matt,
thanks for posting an update.Does SDM state that upper half of 0x199 MSR must be set explicitly to zero by the software?
Hi
It says this: "State transitions are initiated by writing a 16-bit value to the IA32_PERF_CTL register" which implies only eax is written to. However IA32_PERF_CTL reads both edx and eax: For example to turn off 'Turbo' mode bit 1 of edx needs to be set.
It seems that on the 32 bit processor on which the exception does not occur the code behind wrmsr does not care if edx is set to its existing value, ie, unchanged after doing a rdmsr.
However on the 64 bit platofrm with the exception it seems bits 1-31 of edx must be explicitely cleared before wrmsr is run.
>>>However on the 64 bit platofrm with the exception it seems bits 1-31 of edx must be explicitely cleared before wrmsr is run>>>
Thanks for that info.
I have been investigating the issue with the debugger error "no such msr" and I have found that some of the msr registerd can not be written from ring0 code.They are accessible only from SMM mode.It could be accessed for example from BIOS code by writing to I/O port 0x0B2.
I have been investigating the issue with the debugger error "no such msr" and I have found that some of the msr registerd can not be written from ring0 code.They are accessible only from SMM mode.It could be accessed for example from BIOS code by writing to I/O port 0x0B2
I have been investigating the issue with the debugger error "no such msr" and I have found that some of the msr registerd can not be written from ring0 code.They are accessible only from SMM mode.It could be accessed for example from BIOS code by writing to I/O port 0x0B2
Sorry for multiple posts I thought that this is IDZ website issue.