Re: [PATCH 0/7] MIPS: Add extended ASID support

[James Hogan <james.hogan@imgtec.com>]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

On Mon, May 09, 2016 at 08:56:51PM +0100, Maciej W. Rozycki wrote:
> On Mon, 9 May 2016, James Hogan wrote:
> 
> > > > Already PMC-Sierra's RM9000 / E9000 core had an extended ASID field, of
> > > > 12 bits for 4096 ASID contexts.  Afaics this was an extension derived
> > > > in-house back in the wild days before everything had to be sanctioned by
> > > > the architecture folks, so there is nothing in a config register to test
> > > > for it.
> > > 
> > >  Couldn't you just probe it in EntryHi directly, by writing all-ones, 
> > > reading back and seeing how many bits have stuck?
> > 
> > Note, the tlbinv feature in recent versions of MIPS32/MIPS64 arch has
> > EHINV bit in bit 10 (if I remember right) of EntryHi, which marks whole
> > tlb entry as invalid, and the small pages feature (for 1k pages) extends
> > VPN field downwards to bit 11.
> 
>  Yes, but these are not legacy architectures, are they?

Right.

> Since you've got
> bits set across Config registers you don't need to resort to poking at 
> other registers.  Although there are exceptions like PABITS and SEGBITS 
> (we ought to handle this one day actually, for correct unaligned access 
> emulation -- right now you get a repeated AdEL exception in emulation code 
> for what originally was an unaligned out of range kernel XKPHYS access, 
> making it a big pain to debug; I've had a hack for this since 2.4 days, 
> but it should be done properly).
> 
>  In the old days pretty much nothing was recorded in the single Config 
> register (very old chips didn't even have that -- you had to size caches 
> manually for example), but stuff could often be determined via other 
> means, sometimes (like probably here) without detailed checks on PRId.

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]