Re: Does the KA630 have a TB?

[Johnny Billquist <bqt%softjar.se@localhost>]

On 2023-09-24 15:21, Mouse wrote:
> > Yes, it has a translation buffer.  I don't know offhand the size of
> > it.  But you can see about the TBIA and TBIS in
> > https://bitsavers.org/pdf/dec/vax/630/EK-KA630-UG-001_Feb86.pdf,
> > chapter 4.8
>
> That's more or less the same as what EL-00032-00-decStd32_Jan90 says
> about TBIA/TBIS.
>
> > But I seriously doubt the translation buffer in the uVAX II covers
> > anything close to 8M.
>
> I would doubt it too.  It was a first cut (and I may keep it, at least
> optionally, for other reasons anyway).

Should not matter. You should be able to use any size TB.

> > But I also fail to see that it would matter exactly how big it is.
>
> _Exactly_ how big, that probably doesn't matter.  I suspect its size
> matters because that NetBSD version actually does run on the KA630,
> without the TBIA/TBIS usage, whereas when provided with an
> unlimited-size TB (8M entries is enough to cache entries for an entire
> 4G if VM) it fails - and I've added enough debugging code to be
> confident that it's failing because the TB holds stale entries.  The
> only explanations I've come up with are (1) that the KA630 doesn't have
> a TB (which Antonio Carlini refuted) and (2) that it is small enough,
> and/or its replacement policy is such, that the stale entries get
> flushed from the real-hardware version before they can cause trouble.

I think you are wrong here.

> > The population of the TB is done completely hidden from the OS.
>
> Its population, yes.  But, if the OS doesn't flush it correctly - which
> that version of NetBSD doesn't - then its _de_population may not be.

I think you are wrong. See below...

> > And I have a hard time thinking that NetBSD would depend on any
> > specific size of the TB.
>
> I don't think it does, not on any specific size.  I think it, that
> version, just depends on its size and replacement policy being such
> that that stale entries get replaced before they cause trouble.

That would be crazy and broken.

> > I would rather suspect that there is something wrong in your
> > implementation.
>
> Well, yes, since my emulation doesn't behave like the real thing, it
> obviously is incorrect in some respect(s).  I was trying to find out
> what the real thing is like in enough detail to bring my emulation in
> line with it.

So, I seriously doubt that there is even some hidden dependency on some 
size. And the actual size is rather different on different VAXen that 
NetBSD runs on.

But basically, we're talking about the TB now. It's automatically 
populated, but in some situations software needs to explicitly flush it.

So, what are those conditions:
1) If a page translation is updated to somewhere else.
2) If a page goes from being valid to invalid.

Now, these can happen in NetBSD if someone does an munmap(), for 
example, or brk() that shrinks the size. Both of these are examples of 
pages going from valid to invalid.

If you do an mmap() that modifies an existing mapping, that would be an 
example where the translation changes.

But from what you are saying, it sounds like you are hitting problems 
where none of those situations are going on, right?

So, my thinking are context switches, which also affect the TB, since 
you get completely new page tables.

However, there is no need by the kernel to do any explicit invalidation 
in this case, because LDPCTX implicitly should force a TB flush.

So my question to you now is: are you flushing the TB when that 
instruction is executed? Because otherwise I suspect you'd see *exactly* 
what you are reporting... Also note that in this case, it's only 
required to flush all TB that refers to P0/P1 space.

  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