From: Fredrik Noring <noring@nocrew.org>
To: Christoph Hellwig <hch@lst.de>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] MIPS: remove cpu_has_64bit_gp_regs and cpu_has_64bit_addresses
Date: Wed, 25 Mar 2020 12:04:12 +0100 [thread overview]
Message-ID: <20200325110412.GA40881@sx9> (raw)
In-Reply-To: <20200325095435.GA27807@lst.de>
> So from what I can tell this uses a 32-bit kernel and 32-bit userspace,
> and sets both pu_has_64bit_gp_regs and cpu_has_64bit_addresses to 0.
>
> Now if you ever wanted to make use of the 64-bit registeres it would
> require quite some changes, which probably really should have a new
> Kconfig option. In fact a lot of the workaround for the 64-bit
> registeres that are in the code already should be keyed off such an
> option rather than CONFIG_CPU_R5900.
Addresses are always 32-bit for the R5900 (and not even sign extended?),
as I understand, but GPRs are also always 128-bit. The kernel is unable
to disable 64-bit operations and 128-bit multimedia instructions (MMIs)
because the R5900 doesn't implement CP0.Status.UX. [ In other MIPS ISA
implementations, attempting to execute 64-bit operations in 32-bit user
or supervisor mode may cause an reserved instruction exception. ]
The best approach, I think, is to have the kernel properly save/restore
128-bit GPRs in all cases, as MMIs are quite useful and actually would
"mostly" work regardless of any kernel support. I wrote "mostly" because
with o32 the upper 96 bits of the GPRs would be clobbered when switching
contexts unless they are restored by the kernel.
Also of note is that some pieces of hardware require a 64-bit store
instruction, even with a 32-bit kernel. This implies that the kernel
either saves 128 or 64 GPR bits in 32-bit mode too, or, that interrupts
are disabled to avoiding clobbering GPRs in these specific cases.
Fredrik
next prev parent reply other threads:[~2020-03-25 11:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-24 16:15 MIPS ioremap cleanups Christoph Hellwig
2020-03-24 16:15 ` [PATCH 1/6] MIPS: remove cpu_has_64bit_gp_regs and cpu_has_64bit_addresses Christoph Hellwig
2020-03-25 2:36 ` Maciej W. Rozycki
2020-03-25 8:30 ` Christoph Hellwig
2020-03-25 8:55 ` Fredrik Noring
2020-03-25 8:58 ` Christoph Hellwig
2020-03-25 9:24 ` Fredrik Noring
2020-03-25 9:54 ` Christoph Hellwig
2020-03-25 11:04 ` Fredrik Noring [this message]
2020-03-24 16:15 ` [PATCH 2/6] MIPS: cleanup fixup_bigphys_addr handling Christoph Hellwig
2020-03-24 16:15 ` [PATCH 3/6] MIPS: merge __ioremap_mode into ioremap_prot Christoph Hellwig
2020-03-24 16:15 ` [PATCH 4/6] MIPS: split out the 64-bit ioremap implementation Christoph Hellwig
2020-03-24 16:15 ` [PATCH 5/6] MIPS: move ioremap_prot und iounmap out of line Christoph Hellwig
2020-03-24 16:15 ` [PATCH 6/6] MIPS: use ioremap_page_range Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200325110412.GA40881@sx9 \
--to=noring@nocrew.org \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=tsbogend@alpha.franken.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.