New subject: Access to IOPAGE Registers using PDP-11 Opearting Systems

26 Nov 2007

"Jerome H. Fine" <jhfinedp3k at compsys.to> skrev:

...
   Johnny
Billquist wrote:  
 >>> Jerome Fine replies:
>>> Obviously, a SYSTEM request avoids all of the problems at a 
>>> heavy cost in overhead estimated at between 50 and 500 times 
>>> the above two examples.
>>> 
>>> That was sort of what I was thinking about when I asked if 
>>> there was an "fast method (only a few instructions)" to 
>>> access an IOPAGE register.
> 
> Well, in RSX, you have a rather high overhead to set up the 
> mappping to the I/O page, unless it's already mapped in when the 
> task starts. But from there on, there is no overhead at all. It's
> located somewhere in your 16-bit address space. (Note that you
> really don't have to map the I/O page at APR7 in RSX. You can get
> it mapped anywhere if you use the CRAW$/MAP$ or TKB options.)
>   
 That is helpful information.  There might be times when APR7 should 
 not be used. 
Might be, but I can't figure out when. But I  guess if you wanted to map 
something else into memory as well (such as a shared library), which 
wasn't position independent, and which expected to be at APR7...
I just mentioned it since it's technically no difference between any of 
the APRs for a user program.

Anyway, the overhead of mapping in the I/O page is a one time cost.

...
 > However, with normal privileged programs, the I/O
page is always 
> present at APR7 even if you don't do anything. 
...
  Also VERY helpful.  However, if so, then would there
be any reason
 why APR7 could not be mapped to user memory in the normal manner so
 that the user program has a full 65536 bytes of address space, but
 then the PREVIOUS  DATA space is mapped to KERNEL providing the user 
 with complete access to the IOPAGE registers via that 2 instruction 
 example that I gave at the beginning?  I can't see that there would
 be any greater loss of security since being able to change the IOPAGE
  registers either directly or indirectly is just as damaging!

 Please comment? 
You can have a privileged program that isn't mapped to the I/O page. The 
problem is that the kernel sets the PSW at various times for you, so you 
cannot expect to be able to keep control of the previous mode field of 
the PSW from your program. RSX is multitasking. Things can change 
between one instruction and the next in your task. One typical mistake 
people might do is to manipulate the APR registers themself, just 
because they are accessible, and the program is privileged. This won't 
work, since a contect switch can occur at any time, and the APR 
registers are not preserved between context switches. Instead, they are 
recreated from scratch, based on your mapping context every time the 
task is selected to run.

So in that case, it fails not because of security considerations, but 
because of system design. You need to have the I/O page mapped in properly.

Put another way: RSX makes sure the previous mode field is set to user 
at every occasion the system have executed in kernel mode and goes back 
to user mode. That is a security design. To make this different for 
privileged programs would incur extra costs everywhere, whithout any 
real gain. Privileged programs can get around this "problem" anyway, but 
not by running in user mode and expecting the previous mode field to be 
set to kernel.

...

>>>>>>> RSX had a bit more flexibility (opportunity) in this
>>>>>>>  regard.  I believe you can set up a CRAW$ (create 
>>>>>>> address window) directive in either Macro or Fortran
>>>>>>> to achieve the desired result.
>>>>> 
>>>>> Yes with reservation. CRAW$ (create address window) is as
>>>>> a part of doing dynamic remapping of your address space.
>>>>>  However, CRAW$ always required a named memory partition.
>>>>>  You cannot create an address window to an arbitrary
>>>>> memory address. Also, the memory partitions have
>>>>> protections and ownership associated with them.
>>>>> 
>>>>> On most systems, CRAW$ cannot get you access to the I/O 
>>>>> page, simply because normally you don't have an address 
>>>>> space and a partition associated with the I/O page.
>>>>> 
>>>>> But if such a partition is created, then CRAW$, in 
>>>>> combination with MAP$ would allow you to access the I/O 
>>>>> page.
>>>>> 
>>>>> The same thing can also be achieved even without 
>>>>> CRAW$/MAP$, since you can specify mapping that your task
>>>>> should have already at task build time, with the COMMON
>>>>> and RESCOM options to TKB.
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> This seems to be the answer if it is allowed.  Obviously it 
>>> does require giving up that 8192 bytes the have APR7 mapped
>>> to user space.
> 
> Correct.  
 But unnecessary if privileged jobs already have access to the IOPAGE.

 Please comment? 
True, but that already implies that one APR is used.

...
  >>>
There is also another option with E11 that I will make use of
>>>  when I have finished with the HD(X).SYS device driver for 
>>> RT-11.  It turns out that if the memory is being accessed 
>>> sequentially, the average time to reference a single 16 bit 
>>> value in the file under: MOUNT  HD:  FOOBAR.DSK is actually 
>>> less than the time to get/store a single value under EMEM.DLL
>>>  when as few as 8 blocks (2048 words at a time) are being 
>>> referenced. Consequently, setting up a small 4096 byte buffer
>>>  and the associated code to handle to calls to the HD: device
>>>  driver (all standard calls to .ReadF and .WritF in RT-11) is
>>>  actually more efficient since after the values are in the 
>>> buffer inside the program, the values can be referenced and 
>>> modified at "emulated PDP-11" memory speeds.
> 
> You mean that using a device driver, and a device that can access
>  the "normal" memory instead is better. Well, I'm not surprised.
>  What this essentially turns into, is that you're emulating DMA.  
 Actually, under E11, it is almost identical in principle to the VM: 
 device driver which accesses "emulated normal PDP-11 extended
 memory".  The E11 command: MOUNT  HD:  RAM:/SIZE:number-of-blocks 
 makes HD: into a Virtual Memory device which directly uses PC memory. 
"Ram disk" is probably the word I'd use.

...
  However, the  average transfer rate per word for even
a few blocks
 (or a few thousand words) from/into emulated user memory is a small
 fraction of > a normal memory access time. 
True.

...
  In addition, if an operating system caches the blocks
in a file, the
 same speed is achieved. 
Not really. By using a ram disk, you don't need to run through the 
various layers of the operating system to deal with the system call and 
the device handling, even if that ends up just accessing a disk cache.

...
  >>> Of
course, the above solution for sequential references does
>>>  not work when the references are random or when references
>>> are at regular but very large intervals (thousands and even 
>>> millions of  successive values).  For this latter situation,
>>> it may be possible to modify EMEM.DLL so that a single
>>> reference to the IOPAGE register modifies all of the
>>> specified values (over a range of up to many billions of
>>> values).
> 
> Can't comment much, since I don't know exactly what you're trying
>  to do. But speedwise, if you really want something to act like
> fast disk, writing something that behaves like proper DMA is the
> best. You give the device a memory address, a length, and a
> destination address on the device, and let it process the data as
> fast as it can, without involving the PDP-11 after that point.  
 It is just a bit more complicated since the memory address can be
 anywhere in the 4 MB of emulated PDP-11 memory.  So 22 bit address is
 required > - which can be determined during initialization.  The even
 better aspect is that the code (only about a dozen instructions which
 set up the 6 IOPAGE registers) can be in user space which avoids the
 overhead of a system call. 
Why limit yourself to 4 MB?
If you have a device that gives you the storage, you can basically let 
if be of any size you want to.

	Johnny

cAccess to IOPAGE Registers using PDP-11 Opearting Systems