<geist>
PLIC question that I can't quite wrap my head around
<geist>
the interrupt enable registers seem to be back to back for each interrupt context, each at a multiple of 0x80 from the base address in the PLIC register aperture
<geist>
so, makes sense. interrupt context 0 gets 0x0 offset, context 1 at 0x80, context 2 at 0x100, etc
<geist>
but.. what i dont grok is since those are all mashed up within the same page, how does machine mode firmware keep supervisor mode from futzing with interrupt enables for stuff targetted towards machine mode?
<geist>
seems that all hard cpu implementations i've seen assign interrupt context as hart 0 { context 0 = M, context 1 = S }, hart 1 { context 2 = M, context 3 = S }, and so on, so basically every other context is M and then S
<geist>
seems a strategy could be to assign the contexts such that all the M mode ones are on one or more pages, and then the S mode ones are on subsequent pages, and the PMP marks them offline?
<jrtc27>
it doesn't
<jrtc27>
that's one of the things the AIA spec's APLIC fixes
<geist>
got it, okay. makes sense. i guess in current implementations there's no hard IRQs that M mode is intercepting, so it hasn't been an issue yet
<geist>
since it's really only intercepting the machine mode timer, but that's not going through the PLIC
<geist>
looks like the C906 core (and probably other C cores) tried to fix this by adding a permission control register that lets you mark a bunch of the config registers as off limits to S mode
GreaseMonkey has quit [Remote host closed the connection]
junaid_ has joined #riscv
BootLayer has joined #riscv
BootLayer has quit [Read error: Connection reset by peer]
BootLayer_ has joined #riscv
davidlt_ has joined #riscv
rurtty has quit [Quit: Leaving]
vagrantc has quit [Quit: leaving]
<dh`>
all the PLIC stuff seems like a ... bus accident
davidlt_ has quit [Ping timeout: 252 seconds]
davidlt_ has joined #riscv
davidlt_ has quit [Ping timeout: 252 seconds]
<jrtc27>
it's just "my first interrupt controller"
<geist>
jrtc27: yeah that's kinda my take, but i didn't want to say it :)
<geist>
every once in a while though there's something subtle about riscv stuff that just isn't obvious at first glance, was hoping for something like that
<geist>
i ordered mine back in january, but even the amazon one has the same 'will ship in march maybe' thing
<geist>
it's all gated on the same delivery
crossdev has quit [Ping timeout: 268 seconds]
crossdev has joined #riscv
ldevulder has quit [Quit: Leaving]
epony has joined #riscv
ZipCPU_ has joined #riscv
ZipCPU has quit [Ping timeout: 260 seconds]
ZipCPU_ is now known as ZipCPU
BootLayer_ has quit [Quit: Leaving]
junaid_ has quit [Remote host closed the connection]
craigo has quit [Ping timeout: 255 seconds]
jmdaemon has joined #riscv
greaser|q has joined #riscv
greaser|q has joined #riscv
greaser|q has quit [Changing host]
greaser|q is now known as GreaseMonkey
vagrantc has joined #riscv
crossdev has quit [Remote host closed the connection]
<smaeul>
geist: if the PLIC knows the permission level of the bus access, it can limit M-context register access to M-mode itself, without help from PMPs.
<geist>
that's true
<smaeul>
the C9xx permission control register lets you additionally limit access to the S-context registers to M-mode
<geist>
yah was thinking with that you could at least trap-n-emulate if S mode tried to fiddle with the M mode bits
<geist>
but otherwise have unfettered access to S mode bits
___nick___ has joined #riscv
<geist>
the usual ARM method for this sort of thing is to put things in at least separate pages so you can use permissions at that level
<smaeul>
or the hardware does magic based on the NS bit in the bus access
<geist>
yah
<geist>
but really, it's just the PLIC isn't designed yet to be that secure, but the AIA stuff should fix that. i need to sit down and grok that spec soon too
<dh`>
admittedly my first interrupt controller didn't handle this point, but it also didn't operate in an environment where the issue came up
selve has quit [Read error: Connection reset by peer]
<geist>
yah it's only from having to deal with the complexium that is GICv2 and GICv3 that makes me look for these sort of things
<geist>
in general i'm not a fan of registers acting differently based on the mode they come from, but being masked off entirely maybe
<geist>
idea being that something in machine mode that may want to context switch the PLIC for supervisor mode things should be able to see both sets, but supervisor shouldn't see the m mode stuff
<geist>
if you had a reg that say could deal with whatever banked copy it could see based on the mode you'd still want a way for higher priviledged stuff to get to the lower bits