Re: NetBSD in SIMH vax with 512 MB RAM

[Anders Magnusson <ragge%tethuvudet.se@localhost>]

    Den 2023-03-23 kl. 01:38, skrev Kalvis Duckmanton:

On 22/3/23 23:40, Mouse wrote:

[...] - 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.

    Hm, interesting :-) I just realize more than one bug here :-)
    
    First: I/O VA is not at 0xe0000000.  Actually, nothing above
    0xc0000000 can ever be addressed on a VAX.
    But I notice here a bunch of other things that will cause problems. 
    May need a slight explanation below :-)
    
    The S0 space is from 0x80000000 up to 0xBFFFFFFF, which is 1GB.
    Since on VAX all of the kernel virtual space must be allocated
    before the memory management is turned on we have to estimate how
    much kernel virtual memory is needed (that is the last addition,
    early heuristics).
    When this code was written the largest memory in any available
    machine (for me) was less than 128MB.  Most machines had like 16MB.
    
    So; bugs:
    1) As you have noted CASMAGIC may refer to legal memory space. 
    2) Since avail_end is added twice to kvmsize (+ some other tables)
    it will overflow the SLR.
    
    To fix 1) is simple, just changing it 0xfedababe as you recommended.
    Fixing 2) requires slightly more thinking. It is really bad and can
    probably cause all sorts of bugs.
    Since S0 space is what it is, this must be rethinked.
    
    One way to do it would be to just limit the KVM to 1G.  No idea if
    it would be enough or if it would panic the kernel due to out-of-KVM
    space.
    Another way would be to limit the physical memory to 256M and add
    support to not map all of physical memory for large-memory machines
    as a compile-time option.
    
    So, comments welcome :-)
    
    -- Ragge