The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
To: tuhs@minnie.tuhs.org
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [TUHS] Accessing the PDP-11/70 MMU registers and the kernel's u area
Date: Sun, 14 Jun 2020 10:46:43 -0400 (EDT)	[thread overview]
Message-ID: <20200614144643.E4BBF18C09D@mercury.lcs.mit.edu> (raw)

    > From: Diomidis Spinellis

    > From the 2.11 BSD sources I understand that the PDP-11/70 MMU address
    > and data registers, KDSA and KDSD, start at 0172360 and 0172320
    > respectively ...

Expressed as 16-bit addreses, on a PDP-11 with mapping disabled, yes.

    > I checked this by looking at /dev/mem. 

I don't know about 2.11, but in other PDP-11 Unixes, /dev/mem gives access to
the actual CPU memory bus (which on a /34, etc, is the 18-bit address UNIBUS;
on a /70 it's a separate 22-bit address bus).  In the /70 memory address
space, the 'I/O page' (which is where the PxR's live) is at the top end of it,
i.e. the registers are at 017772360 (KDSAR0), etc.

    > What am I missing?

PDP-11's have a plethora of address spaces, of different sizes. You need to
always be aware of which one you're working in.

    > My goal is to access from the console the kernel's u area.  According to
    > mem(4) and the symbols in /unix, this should be at address 0140000.

In the kernel virtual address space, yes.

    > Indeed, accessing it through /dev/kmem I get the expected results for
    > e.g. u_comm and u_uid.

Because /dev/kmem gives access to kernel address space for the _current_
process.

    > I have been unable to find it in the machine's physical memory

By far and away the easiest thing, for the _current_ process, is to
use /dev/kmem, which automagally applies the correct mapping.

For other processes, if the process is swapped in, there's some field in the
proc structure which says where in physical memory it us. IIRC, the user
struct and the kernel stack are stored in the very bottom of that.

(This article:

    http://gunkies.org/wiki/Unix_V6_dump_analysis#Memory_layouts

goes into some detail for V6. Not sure how different 2.11 is; I know it uses
one block of kernel address space to map in code overlays, but I don't know
all the details of how it works.)

Anyway, using that, one could read the user area in /dev/mem, at the
appropriate location.

For swapped-out processes, a similar algorithm applies, but you'll
have to look in the swap device (obviously).

     Noel

             reply	other threads:[~2020-06-14 14:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-14 14:46 Noel Chiappa [this message]
2020-06-14 15:52 ` Warner Losh
2020-06-14 16:13 ` Diomidis Spinellis
  -- strict thread matches above, loose matches on Subject: below --
2020-06-14  8:33 Diomidis Spinellis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200614144643.E4BBF18C09D@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).