- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The address of IA_PERF_CTL is 0x199.Try to access this register by its address.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
> 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>>Well on win 7 I get an exception, ie BSOD>>>
Can you search for installed exception handlers with the kernel mode command idt -a.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>>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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page