How to reliably detect USER or SUPERVISOR mode across CPUs
-
- Aurora
- Posts: 931
- Joined: Sat Oct 25, 2014 9:53 am
How to reliably detect USER or SUPERVISOR mode across CPUs
Hi everyone
I am trying to design a routine that when called might be in ether of USER or SUPERVISOR privilege modes and, at some point will need to protect a heap memory allocation by temporarily switching to SUPERVISOR mode if not already there.
Before returning, the routine should be back in the privilege mode it was called-in.
Reading the 68k Programmers manual, I note that on a 68000/68008, I could safely use the MOVE SR, <ea> instruction (and then test the appropriate U/S bit in the destination) regardless of the current privilege mode, but that on the 68010 etc, this instruction is itself privileged and would cause an exception if executed in USER mode.
Ideally, I'd like the resultant code to be agnostic to processor generation (real or emulated)...
Has anyone already thought a neat and reliable approach to this?
Happy Easter Monday
I am trying to design a routine that when called might be in ether of USER or SUPERVISOR privilege modes and, at some point will need to protect a heap memory allocation by temporarily switching to SUPERVISOR mode if not already there.
Before returning, the routine should be back in the privilege mode it was called-in.
Reading the 68k Programmers manual, I note that on a 68000/68008, I could safely use the MOVE SR, <ea> instruction (and then test the appropriate U/S bit in the destination) regardless of the current privilege mode, but that on the 68010 etc, this instruction is itself privileged and would cause an exception if executed in USER mode.
Ideally, I'd like the resultant code to be agnostic to processor generation (real or emulated)...
Has anyone already thought a neat and reliable approach to this?
Happy Easter Monday
Re: How to reliably detect USER or SUPERVISOR mode across CPUs
Does section 10:12 in the Qdos/SMSQ Reference manual do anything for you?
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
-
- Aurora
- Posts: 931
- Joined: Sat Oct 25, 2014 9:53 am
Re: How to reliably detect USER or SUPERVISOR mode across CPUs
Darn it - I thought I had researched thoroughly
Thanks Per.
So, what does it mean I wonder when the Guide states 'Therefore, all reads of the status register are emulated.'
Does this mean that MOVE SR, <ea> can be used and, if it does cause an exception due to running on a later processor, that SMSQE will handle the exception in software and effectively action the instruction before returning from the exception handler?
Thanks Per.
So, what does it mean I wonder when the Guide states 'Therefore, all reads of the status register are emulated.'
Does this mean that MOVE SR, <ea> can be used and, if it does cause an exception due to running on a later processor, that SMSQE will handle the exception in software and effectively action the instruction before returning from the exception handler?
- janbredenbeek
- Super Gold Card
- Posts: 633
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
Re: How to reliably detect USER or SUPERVISOR mode across CPUs
Yes.martyn_hill wrote:Darn it - I thought I had researched thoroughly
So, what does it mean I wonder when the Guide states 'Therefore, all reads of the status register are emulated.'
Does this mean that MOVE SR, <ea> can be used and, if it does cause an exception due to running on a later processor, that SMSQE will handle the exception in software and effectively action the instruction before returning from the exception handler?
Another way, which doesn't require a test of the S flag, would be to define your own TRAP (#5 to #15) for it and activate your own exception table. This ensures that your code executes in supervisor mode. Of course it should end with a RTE which will restore the SR on return.
Jan.
Re: How to reliably detect USER or SUPERVISOR mode across CPUs
Im not very well acquainted with this area of the OS as I have had little need for it. You may find the answer to this by looking at dev8_smsq_smsq_privv_asm, which deals with "privilege violation recovery".martyn_hill wrote:So, what does it mean I wonder when the Guide states 'Therefore, all reads of the status register are emulated.'
If in doubt try it out!Does this mean that MOVE SR, <ea> can be used and, if it does cause an exception due to running on a later processor, that SMSQE will handle the exception in software and effectively action the instruction before returning from the exception handler?
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
Re: How to reliably detect USER or SUPERVISOR mode across CPUs
Defining your own traps is fine for jobs, but would that be a good idea for a global device driver?janbredenbeek wrote:Another way, which doesn't require a test of the S flag, would be to define your own TRAP (#5 to #15) for it and activate your own exception table. This ensures that your code executes in supervisor mode. Of course it should end with a RTE which will restore the SR on return.
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
-
- Aurora
- Posts: 931
- Joined: Sat Oct 25, 2014 9:53 am
Re: How to reliably detect USER or SUPERVISOR mode across CPUs
Thanks Jan and Per - I have enough now to make the next step
- janbredenbeek
- Super Gold Card
- Posts: 633
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
Re: How to reliably detect USER or SUPERVISOR mode across CPUs
Probably not, but that wasn't mentioned in the original post.pjw wrote:Defining your own traps is fine for jobs, but would that be a good idea for a global device driver?
Speaking of which, I recently discovered such a thing in the SD card driver for the Q68 supplied with Minerva. It was a TRAP #14 in the read sector code, probably a leftover from debugging as it does nothing if you haven't activated your own trap vectors. But it was quite embarassing to see the monitor screen popping up when doing a DIR!
Jan.
Re: How to reliably detect USER or SUPERVISOR mode across CPUs
How might detecting this tie in with detecting and enabling caches on the 68000, 68020, 68030 and 68060?
Re: How to reliably detect USER or SUPERVISOR mode across CPUs
Enabling cache on a 68000 is REALLY hard.Dave wrote:How might detecting this tie in with detecting and enabling caches on the 68000, 68020, 68030 and 68060?