[...] - I noticed that when SIMH is configured with 512MB of memory, the calculated size of the system page table ends up being a bit larger than the 2^21 entries needed to map all of system space.That's odd. Maybe it's reserving enough space for _two_ copies of physical memory or something?
I think that's exactly what's happening - vax/pmap.c:calc_kvmsize() starts like this:
static vsize_t
calc_kvmsize(vsize_t usrptsize)
{
vsize_t kvmsize, bufsz;
/*
* Compute the number of pages kmem_arena will have.
*/
kmeminit_nkmempages();
/* All physical memory */
kvmsize = avail_end;
/* User Page table area. This may be large */
kvmsize += (usrptsize * sizeof(struct pte));
/* Kernel stacks per process */
kvmsize += (USPACE * maxproc);
/* kernel malloc arena */
kvmsize += nkmempages * PAGE_SIZE;
/* IO device register space */
kvmsize += (IOSPSZ * VAX_NBPG);
/* Pager allocations */
kvmsize += (pager_map_size + MAXBSIZE);
/* Anon pool structures */
kvmsize += (physmem * sizeof(struct vm_anon));
/* kernel malloc arena */
kvmsize += avail_end;
avail_end is the size of physical memory. Note that it's being
added to kvmsize twice; the returned kvmsize is then used to
calculate the length of the system page table.
So I think this is why I don't see a length violation when
accessing a nominally-invalid address such as $CASMAGIC
(0xbedababe) near the end of system space and thus why the logic
in vax/trap.c to restart the CAS sequence isn't invoked - its
preconditions are no longer met as $CASMAGIC is no longer beyond
the end of the system page table and a T_PTELEN trap is thus not
generated. Changing $CASMAGIC to an address somewhere above the
system region restores the expected behaviour in at least SIMH. I
used 0xfedababe but maybe it should be something just below the
I/O VA space at 0xe0000000.
I also think that's a theoretical bug;
<snip>
Oh, agreed - but it is odd.
cheers
kalvis