Add scontext2 alias for scontext

[ernie-sifive]

In the interest of making scontext usable, this PR suggests an alternate CSR address (scontext2 at 0x5a8) through which to access it that is consistent with its desired accessibility, namely Supervisor RW. Retaining the existing scontext register at 0x7aa maintains backward compatibility.

I am suggesting a CSR address consistent with mcontext at 0x7a8 but in the Supervisor CSR range per convention outlined in the RISCV Privileged Architecture Spec. I don't know how CSR numbers are allocated, so assuming reaction to this idea is favorable, there might be an additional step to request this allocation.

[timsifive]

This makes sense to me.
Like you, I don't know how to apply for a supervisor CSR number. Can you e-mail the privileged group, or somebody else who is likely to know?

[ernie-sifive]

@aswaterman There has been customer and internal interest in adding an option to the core trigger hardware to qualify breakpoints based on a context ID for systems that reuse virtual addresses in multiple contexts.  What do you think of an alias for scontext in a range that is accessible in S-mode?

[aswaterman]

Wouldn't it make sense to use the ASID for this rather than inventing a new concept?

[timsifive]

The original proposal actually used ASID, and then was changed to this format. The discussion is at #363 (comment)

Using satp seems less flexible because it's limited to just address translation. But it is faster when context switching.

I'd lean towards not switch to asid, because scontext is already in the ratified 0.13 debug spec.

[aswaterman]

OS probably won't use the feature as specified, since it doesn't affect OS functionality and adds context-switch latency, so it will likely end up being vestigial. OTOH, OS will be forced to use ASID for performance reasons.

The "scontext is already ratified" argument isn't especially compelling, since satp.ASID has already been ratified, too.

[ernie-sifive]

ASID width can be small, even 0. When the OS recycles an ASID, it will make ASID useless for trigger qualification.

From a hardware perspective, an scontext register seems like it would add less hardware than an ASID since ASID affects address translation and isn't just a simple read/write register field.

[aswaterman]

HW-cost argument doesn't hold up (can implement ASID bits but have them not do anything), but ASID-recycling argument is valid.

Is there precedent for this kind of feature in Linux ports to other ISAs? Have they taken the same approach?

[bruceable]

Yes, both ARM and MIPS have implemented context registers for triggering and I believe trace qualification. I can find references but it might take a half hour or so.

…

On Wed, Jul 29, 2020 at 9:49 AM Andrew Waterman ***@***.***> wrote: HW-cost argument doesn't hold up (can implement ASID bits but have them not do anything), but ASID-recycling argument is valid. Is there precedent for this kind of feature in Linux ports to other ISAs? Have they taken the same approach? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#535 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJOFJADDQM2UATCBF3IPAADR6BHJDANCNFSM4PHUBHXA> .

[aswaterman]

No need for citations; just trying to make sure we’re on well-trodden ground here.

Are those registers updated as part of the context-switch code? I assume they’re disabled by default and enabled by a Kconfig option, given that not all implementations support the feature?

[pdonahue-ventana]

ARMv8 has CONTEXTIDR_EL2 and CONTEXTIDR_EL1 that are separate from VMID and ASID. From D2.1.2 of ARMv8 F.b:

A CONTEXTIDR_ELx identifies the current Context ID, that is used by:
​> ​• The debug logic, for breakpoint and watchpoint matching.
​> ​• Implemented trace logic, to identify the current process.

​My recollection from ~4 years ago is that the Linux kernel is built by default without support for context switching CONTEXTIDR_EL1. If you want to use it for debug/trace, you have to build a kernel with that enabled. (I couldn't quickly find a reference for this so you may not want to take my word for it.)

[aswaterman]

Thanks, Paul; you answered my question as I was typing it.

[bruceable]

On Wed, Jul 29, 2020 at 10:12 AM Andrew Waterman ***@***.***> wrote: No need for citations; just trying to make sure we’re on well-trodden ground here. Are those registers updated as part of the context-switch code? I assume they’re disabled by default and enabled by a Kconfig option, given that not all implementations support the feature?

The short answer is 'yes', at the time of the context switch. Not that familiar with Linux kernel builds but the Kconfig option makes sense. I found a snipit of ARM code from 2012 here: https://elixir.bootlin.com/linux/latest/source/arch/arm/mm/context.c The register concatenates 24 bits of PID with 8 bits of ASID. In the R5 arch, there is no ASID so 32 bits of PID. /* * On ARMv6, we have the following structure in the Context ID: * * 31 7 0 * +-------------------------+-----------+ * | process ID | ASID | * +-------------------------+-----------+ * | context ID | * +-------------------------------------+ * * The ASID is used to tag entries in the CPU caches and TLBs. * The *context ID is used by debuggers and trace logic, and** * should be unique within all running processes.* * * In big endian operation, the two 32 bit words are swapped if accessed * by non-64-bit operations.* */ **... *#ifdef CONFIG_PID_IN_CONTEXTIDR <https://elixir.bootlin.com/linux/latest/K/ident/CONFIG_PID_IN_CONTEXTIDR> static int contextidr_notifier <https://elixir.bootlin.com/linux/latest/C/ident/contextidr_notifier>(struct notifier_block <https://elixir.bootlin.com/linux/latest/C/ident/notifier_block> *unused <https://elixir.bootlin.com/linux/latest/C/ident/unused>, unsigned long cmd, void *t){ u32 <https://elixir.bootlin.com/linux/latest/C/ident/u32> contextidr; pid_t <https://elixir.bootlin.com/linux/latest/C/ident/pid_t> pid <https://elixir.bootlin.com/linux/latest/C/ident/pid>; struct thread_info <https://elixir.bootlin.com/linux/latest/C/ident/thread_info> *thread <https://elixir.bootlin.com/linux/latest/C/ident/thread> = t; if (cmd != THREAD_NOTIFY_SWITCH <https://elixir.bootlin.com/linux/latest/C/ident/THREAD_NOTIFY_SWITCH>) return NOTIFY_DONE <https://elixir.bootlin.com/linux/latest/C/ident/NOTIFY_DONE>; pid <https://elixir.bootlin.com/linux/latest/C/ident/pid> = task_pid_nr <https://elixir.bootlin.com/linux/latest/C/ident/task_pid_nr>(thread <https://elixir.bootlin.com/linux/latest/C/ident/thread>->task <https://elixir.bootlin.com/linux/latest/C/ident/task>) << ASID_BITS <https://elixir.bootlin.com/linux/latest/C/ident/ASID_BITS>; asm volatile <https://elixir.bootlin.com/linux/latest/C/ident/volatile>( " mrc p15, 0, %0, c13, c0, 1\n" " and %0, %0, %2\n" " orr %0, %0, %1\n" " mcr p15, 0, %0, c13, c0, 1\n" : "=r" (contextidr), "+r" (pid <https://elixir.bootlin.com/linux/latest/C/ident/pid>) : "I" (~ASID_MASK <https://elixir.bootlin.com/linux/latest/C/ident/ASID_MASK>)); isb <https://elixir.bootlin.com/linux/latest/C/ident/isb>(); return NOTIFY_OK <https://elixir.bootlin.com/linux/latest/C/ident/NOTIFY_OK>;} ... —

…

You are receiving this because you commented. Reply to this email directly, view it on GitHub <#535 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJOFJAC6JXKAEOI6V4RHITTR6BJ6JANCNFSM4PHUBHXA> .

[ernie-sifive]

So back to the original question, @aswaterman: is the 0x5a8 CSR address for scontext acceptable and if so, can the Debug TG just use it or is there a process to follow with the Privileged Spec TG to get this address allocated?

[aswaterman]

The proposal and the rationale need to go to the tech-privileged list to get feedback from others, since this is a full-blown privarch feature.

[jscheid-ventana]

​My recollection from ~4 years ago is that the Linux kernel is built by default without support for context switching CONTEXTIDR_EL1. If you want to use it for debug/trace, you have to build a kernel with that enabled. (I couldn't quickly find a reference for this so you may not want to take my word for it.)

Yes, because it is not useful for self-hosted debug, where the PID/ASID association is easy to maintain. It's optional because it's only useful for external debug/trace use of triggers, where the ASID could change underneath you or be reused/swapped during a session.

[ernie-sifive]

@timsifive The scontext change to the Privileged Spec in riscv/riscv-isa-manual#559 has been merged, so this PR is ready for final review and merging.

[timsifive]

I'll merge this tomorrow, assuming there are no other comments.

[timsifive]

Why does mscontext say it's included for backward compatibility, but mcontext doesn't say the same thing?

@pdonahue-ventana, thoughts?

[ernie-sifive]

0x7a8 is the mcontext CSR index. 0x7aa is in an M-mode only access range so wasn't suitable for scontext, which should be writable in S-mode. So we moved scontext to 0x5a8, which is writable in S-mode, but left this 0x7aa alias in the doc in case there was an implementation that used it.

[pdonahue-ventana]

Yep. Debug 0.13 didn't have the benefit of an architecture review committee which would presumably notice the improper CSR number.

[timsifive]

That all makes sense, just not sure why we have mcontext at all. But maybe it's not related to this change. I'll e-mail for more discussion.