topic >>>Perhaps there is a bug in in Intel® ISA Extensions

IA32_PERF_CTL on X64 error

Matt_S_3 — Thu, 28 Feb 2013 16:56:17 GMT

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

Bernard — Thu, 28 Feb 2013 17:25:00 GMT

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

Bernard — Thu, 28 Feb 2013 17:46:25 GMT

The address of IA_PERF_CTL is 0x199.Try to access this register by its address.

Obviously IA_PERF_CTRL is a

Matt_S_3 — Fri, 01 Mar 2013 08:29:00 GMT

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 this register

Bernard — Fri, 01 Mar 2013 09:30:00 GMT

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

Matt_S_3 — Fri, 01 Mar 2013 15:14:31 GMT

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

Bernard — Sat, 02 Mar 2013 05:33:14 GMT

>>>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,

Matt_S_3 — Sat, 02 Mar 2013 10:28:55 GMT

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

Bernard — Sat, 02 Mar 2013 13:27:32 GMT

>>>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

Matt_S_3 — Sat, 02 Mar 2013 14:41:03 GMT

> 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

SergeyKostrov — Sat, 02 Mar 2013 20:47:24 GMT

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

Bernard — Sat, 02 Mar 2013 21:10:23 GMT

>>>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

Bernard — Sun, 03 Mar 2013 08:28:00 GMT

>>>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

Matt_S_3 — Sun, 03 Mar 2013 08:37:00 GMT

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

Bernard — Sun, 03 Mar 2013 08:45:36 GMT

>>>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?

Matt_S_3 — Sun, 03 Mar 2013 08:48:50 GMT

>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

Bernard — Sun, 03 Mar 2013 08:57:35 GMT

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

Matt_S_3 — Sun, 03 Mar 2013 09:01:55 GMT

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

Bernard — Sun, 03 Mar 2013 09:23:00 GMT

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

Matt_S_3 — Mon, 04 Mar 2013 17:06:10 GMT

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.