Em Fri, Jan 29, 2021 at 10:48:52AM +0800, Tiezhu Yang escreveu:

On 01/28/2021 05:15 AM, Thomas Bogendoerfer wrote:

quoted

On Tue, Jan 05, 2021 at 11:18:06AM +0100, Peter Zijlstra wrote:

quoted

On Tue, Jan 05, 2021 at 11:45:37AM +0800, Jiaxun Yang wrote:

quoted

在 2021/1/4 下午6:59, Peter Zijlstra 写道:

quoted

On Tue, Dec 29, 2020 at 08:55:59PM +0800, Tiezhu Yang wrote:

quoted

+u64 perf_reg_abi(struct task_struct *tsk)
+{
+	if (test_tsk_thread_flag(tsk, TIF_32BIT_REGS))
+		return PERF_SAMPLE_REGS_ABI_32;
+	else
+		return PERF_SAMPLE_REGS_ABI_64;
+}

So we recently changed this on x86 to not rely on TIF flags. IIRC the
problem is that on x86 you can change the mode of a task without the
kernel being aware of it. Is something like that possible on MIPS as
well?

Hi all,

In MIPS world it's impossible to raise a thread to 64bit without kernel
aware.
Without STATUS.UX set it will trigger reserved instruction exception when
trying
to run 64bit instructions.

The other way around is the case on x86, a 64bit program can create and
execute 32bit code sections without the kernel being aware. But if
clearing STATUS.UX has the same issue as setting it, that should not be
a problem for you.

quoted

However it may be possible to run with 32bit ABI without
TIF_32BIT_REGS if user program didn't get ELF ABI right. I think
that's out of our current consideration.

Fair enough.

quoted

quoted

The thing x86 does today is look at it's pt_regs state to determine the
actual state.

It is possible to look at pt_regs Status.UX bit on MIPS. But it seems
unnecessary
as user can't change it.

Ok, good. Then no objection, proceed! :-)

this patch aims more to mips-next, while patch 2 and 3 are targeting
tools/perf. Should I take them into mips-next, too ?

If it is possible, I prefer to merge this three patches together
through mips-next tree.

The kernel part should go via the mips-next tree, the tooling I can
process, that is how these things go in other cases where kernel and
tooling changes for some new feature are needed.

This helps making sure tooling is not in lockstep with the kernel, one
should be able to use a new tool in an old kernel and vice-versa.

- Arnaldo