Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD in SIMH vax with 512 MB RAM



On 2023-03-23 16:25, 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.  [...SLR gets a value >0x200000...]
I [] think that's a theoretical bug; EL-00032-00-decStd32_Jan90 says
[...SLR values outside 0..200000 are reserved...]
Let's first of all agree that a page table size larger than 2^21
entries is pointless.

Well, worse than pointless; it could completely break operation.

From a hardware point of view? No. It would just waste memory. So - pointless. Remember, the system page table is just a bunch of ram in your physical memory.

But...

The MMU will pick which page table to use based on the top two bits
of the virtual address.  [...]

If the P0LR, P1LR, and SLR values are within range, yes.  If not, it
might not[%]; as I read the VARM, an implementation could, for example,
treat the system region (80000000-bfffffff) and reserved region
(c0000000-ffffffff) as a single range, with the SLR specifying how much
of it is accessible.  That's well within the latitude "UNDEFINED
operation" permits, as I read it.

If you read 4.4.3 of the VARM, it clearly states that the first check on the virtual address is on the top 2 bits, and any check after that is based on those two bits. And if they are <11>, it's automatically a length violation. No checking of SLR happens. And if it is <10>, then a zero extended VA<29:9> is checked against the SLR for possible length violation. So if SLR is 200000, then if the VA<31:30> is <10> then you cannot get a length violation compared to SLR as long as the SLR is within the defined acceptable values. If SLR is greater, then everything is undefined.

In practice, you could implement this in various ways, but clearly the VARM states that if you try to address 0xc000 0000, you *must* get a length violation, no matter what SLR might be.

Not that we should depend on such a thing, of course, possibly
excepting very-model-dependent code.

I would only do that if it turned out that some specific model actually violated VARM and this was a workaround for such bugs.

[%] I see similar text specifying that P0LR and P1LR have similar
     restrictions to the 0..200000 range, with values outside that
     producing UNDEFINED operation, except for an odd note that "Writing
     P1LR<31> has no effect.  The bit always reads as 0.".

That's a weird one...???

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


Home | Main Index | Thread Index | Old Index