| Author |
Message |
|
|
Post subject: Ring 0 Code
 Posted: Apr 25, 2008 - 01:58 PM
|
|
New Member
Joined: Jul 24, 2007
Posts: 4
|
|
I am trying to write a simple driver for a timer device. The board has an AMD GX500, which uses the AMD CS5536 Companion Device, and the timer that I want to use is on this companion device.
The problem I am running into is that to set up this timer properly, I need to access a couple of MSRs (Machine Specific Registers), through the use of RDMSR and WRMSR assembly instructions.
Even if I call 'ThreadCtl(_NTO_TCTL_IO, 0)' to get I/O priveledges for my code, I still generate a memory fault when I try to execute either of these instructions to access a MSR.
Documentation says that RDMSR and WRMSR can only run from Ring 0, yet the QNX Knowledge Base (QNX.000009784) article says that Ring 0 is only accessible from the kernel.
Does anyone have some suggestions as to how to read/write MSR's from a QNX application?
EDIT : I should probably add, although its implied by stating that I'm running on an AMD GX500, that this question is very x86 specific. |
|
|
| |
|
|
|
 |
|
|
|
Post subject: RE: Ring 0 Code
Posted: Apr 25, 2008 - 03:41 PM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 1045
|
|
| Why do you think that you need to access an MSR to control the timer on an external timer? |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Ring 0 Code
Posted: Apr 25, 2008 - 07:18 PM
|
|
QNX Master
Joined: Sep 01, 2002
Posts: 2783
|
|
| You can run ring 0 instructions from an ISR. |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Ring 0 Code
Posted: Apr 25, 2008 - 08:32 PM
|
|
QNX Master
Joined: Jul 11, 2002
Posts: 600
|
|
|
mario wrote:
You can run ring 0 instructions from an ISR.
Or from a TraceEvent handler... although, like mitch, I wonder what kind of hardware design would necessitate this (would be ugly on any virtual mode operating system). |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Ring 0 Code
Posted: Apr 25, 2008 - 09:16 PM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 1045
|
|
This has gotten me thinking. What is the point of privileged processes not running in ring 0? There are two justifications for limiting what a process can do. Security is not an issue for privileged processes unless you are playing defensive, and think that a process that could clear your hard drive is somehow better than one that could cause a double fault. The other reason is to keep you out of trouble. But if you can get into trouble anyway, via an interrupt, what is the point?
I was thinking about this, because after I read mario's comment, it occured to me that you could just put whatever code you wanted to, into a timer interrupt, and have it executed within a timer tick. This seems to be a rather awful contortion. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Ring 0 Code
Posted: Apr 26, 2008 - 03:29 PM
|
|
QNX Master
Joined: Sep 01, 2002
Posts: 2783
|
|
My educated guess is that getting in and out ring 0 would probably be an expensive operation.
In fact i don't think you can get into ring 0 programatically, hence if the kernel switch to some other ring ( 3 ?) to run the ISR then it has no mean of getting back into ring 0 when getting back into the kernel code. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Ring 0 Code
Posted: Apr 26, 2008 - 03:50 PM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 1045
|
|
| By expensive, do you mean relative to the executing the ISR? I guess this could be an issue. Of course it is done all the time during context switching, so it can't be too bad. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Ring 0 Code
Posted: Apr 28, 2008 - 07:45 AM
|
|
Active Member
Joined: Oct 21, 2003
Posts: 49
|
|
Hi!
Did someone use Ring0() mkernel call for such things?
Looking to a source code of handler can say that it MAY solve a problem of MSR access.
--
WBR,
AG
PS: Access to MSRs in timer ISR for setting up some HW looks ugly for me... Sorry. |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Re: RE: Ring 0 Code
Posted: Apr 28, 2008 - 01:01 PM
|
|
QNX Master
Joined: Sep 01, 2002
Posts: 2783
|
|
|
maschoen wrote:
By expensive, do you mean relative to the executing the ISR? I guess this could be an issue. Of course it is done all the time during context switching, so it can't be too bad.
No I mean on top of the overhead of the ISR. I beleive the processor goes to ring 0 automaticaly when an interrupt occurs, so going to some other ring mode and back to 0 within an ISR is not going to be pretty.
This is just an educated guess I have never look at this stuff in detail. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Re: RE: Ring 0 Code
Posted: Apr 28, 2008 - 03:01 PM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 1045
|
|
| I think getting out of Ring0 is just a matter of flipping a bit in the stack and doing a RET to jump to the ISR. As far as getting back to Ring0, I think it's just a jmp through a gate. Now the overhead on the latter might be something they wanted to avoid. On the other hand, maybe they understand that you might want to mask/unmask an interrupt, or turn them all off. I don't think you can do that without Ring0. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Re: RE: Ring 0 Code
Posted: Apr 28, 2008 - 03:16 PM
|
|
QNX Master
Joined: Sep 01, 2002
Posts: 2783
|
|
| What do you mean by jmp through a gate? |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Re: RE: Ring 0 Code
Posted: Apr 28, 2008 - 04:09 PM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 1045
|
|
| You may recall that a software interrupt can cause a ring change. Likewise the OS can setup a jump gate. You jmp to this address and the hardware changes context. I think you set this up in the selector table. |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Re: RE: Re: RE: Ring 0 Code
Posted: Apr 28, 2008 - 05:48 PM
|
|
QNX Master
Joined: Jul 11, 2002
Posts: 600
|
|
|
maschoen wrote:
You may recall that a software interrupt can cause a ring change. Likewise the OS can setup a jump gate. You jmp to this address and the hardware changes context. I think you set this up in the selector table.
Of course, this discussion is academic, since the mechanism exists to run interrupt handlers in user mode (InterruptAttachEvent).
The purpose of an O/S is not to disallow an unsafe design, but to allow a safe design. You don't have to use InterruptAttach; and, in fact, IMO there is seldom a valid reason to use it. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Re: RE: Re: RE: Ring 0 Code
Posted: Apr 28, 2008 - 06:16 PM
|
|
QNX Master
Joined: Jun 25, 2003
Posts: 1045
|
|
| Correct me if I'm wrong please. When you do an InterruptAttachEvent, your code is scheduled, so it may or may not run soon after the interrupt handler returns. With InterruptAttach, your code runs before the interrupt handler returns. In many cases this difference is not crucial or even significant, but not always. Of course in other situations, it may be a superior design. |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Re: RE: Re: RE: Re: RE: Ring 0 Code
Posted: Apr 28, 2008 - 07:17 PM
|
|
QNX Master
Joined: Jul 11, 2002
Posts: 600
|
|
|
maschoen wrote:
Correct me if I'm wrong please. When you do an InterruptAttachEvent, your code is scheduled, so it may or may not run soon after the interrupt handler returns. With InterruptAttach, your code runs before the interrupt handler returns. In many cases this difference is not crucial or even significant, but not always. Of course in other situations, it may be a superior design.
The interrupt thread is indeed scheduled; and thus you (the system designer) determine exactly when it is placed on the CPU. If you set the priority of the pulse (attached with InterruptAttachEvent) to 255, it will be the first thread scheduled when the kernel exits (assuming that there are no other READY threads at priority 255). If you give it a lower priority than 255, then presumably it is because there is some other task that has a higher priority. |
|
|
| |
|
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
