Re: [PATCH v2] MIPS: Add basic R5900 support

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

 



Hi Fredrik,

> > > I suspect 63:32 are the critical bits of the upper 96 bits since SD/LD
> > > is sufficient. Summery of observations thus far: save/restore works with
> > > SQ/LQ and SD/LD, but not SW/LW, in a 32-bit kernel ceteris paribus.
> > 
> >  This does look intriguing.
> 
> I believe the simple answer to this mystery is that addresses are not
> supposed to be sign-extended, given the look of $31 below. What are
> your thoughts on this?
[...]
> $28   :
>  ffffffff81f70000
>  ffffffff81f71bf8
>  ffffffff815010f8
>  00000000800bed80
> Hi    : 00000000
> Lo    : 00000048
> epc   : 800beeb0 unmap_page_range+0x3cc/0x664
> ra    : 00000000800bed80 unmap_page_range+0x29c/0x664

 Hmm, this looks consistent with the TX79 manual:

"6.2.1 Virtual Address Space

The C790 only implements 32 bits of virtual address space.  There is no 
requirement for address sign extension and no checking will be done on the 
upper 32 bits of the address."

and then say in the JAL instruction description:

"I: GPR[31] 63..0 <- zero_extend (PC + 8)"

It does not matter for the user mode where bit #31 is 0 and therefore both 
zero-extension and sign-extension produce the same result, so the typical 
PIC code sequence used to determine its own location, i.e.:

	la	$2, 0f
	bltzal	$0, 0f
0:
	subu	$2, $31, $2

will work correctly, not causing UB with the SUBU instruction.

 However it does cause complications for the kernel in that the value of 
$ra retrieved cannot be readily used for 32-bit calculations and has to be 
treated with SLL by 0 first.  You'll have to audit the arch/mips subtree 
for any such $ra use for calculation; hopefully are there's none.

 I wonder why they broke it like this -- was it a silly deliberate choice 
or merely an oversight (erratum) they chose to document rather than fix? 
For a change they do implement MFC0 with sign-extension, so retrieving 
e.g. CP0.EPC will see kernel addresses correctly sign-extended.

 Anyway, as noted above that shouldn't cause a problem with user software 
and I think that any corruption you can see comes from elsewhere.  You'll 
have to paper this $ra non-sign-extension issue over somehow to proceed 
though.

  Maciej


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux