heat__ has quit [Read error: Connection reset by peer]
heat__ has joined #riscv
BootLayer has quit [Quit: Leaving]
levitating has joined #riscv
levitating has quit [Remote host closed the connection]
levitating_ has joined #riscv
dhoffman has joined #riscv
heat__ is now known as heat
Tenkawa has quit [Quit: Was I really ever here?]
<dhoffman>
i have some question about the Linux RISC-V boot flow around the MMU. Here's my understanding of how it works in QEMU (at least): Linux creates a bogus root-page node (PPN is NULL, not marked valid), configures the SATP to point to the instruction after SATP is updated, updates the SATP with the bogus root page value, traps into the next instruction and finishes configuring the MMU at that point. Is there
<dhoffman>
any document going over exactly how this transition should work?
<palmer>
dhoffman: no, and it's a bit fragile. It's been on the TODO list to write down the rules (and fix the fragility if we can), but nobody's gotten around to it
<dhoffman>
SATP.MODE is never BARE (as far as I can tell, it's hard to figure these things out through GDB) and the trap seems to be delegated to S-mode, so it seems like the MMU should continue to function, which would mean the exception handler would trigger *another* instruction page fault exception and not continue with the initialization
<dhoffman>
palmer: at least it's not just me
levitating_ has quit [Ping timeout: 248 seconds]
<dhoffman>
palmer: if it helps i'm only interested in the QEMU behavior. I posted this question on the QEMU IRC but nobody responded (makes sense considering it's pretty architecture-specific)
levitating_ has joined #riscv
Andre_Z has quit [Ping timeout: 264 seconds]
Narrat has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
levitating__ has joined #riscv
<jrtc27>
why do you think any of this is specific to QEMU?
<jrtc27>
the only thing platform-specific that's relevant is the physical address at which the kernel has been loaded
<dhoffman>
i don't think any of this is specific to QEMU
<ball>
Does QEMU boot in a similar way to RISC-V hardware?
<jrtc27>
yes
<dhoffman>
but if there is no documentation for this fragility in the spec, then QEMU is the next place i'd imagine it would be written/discussed
<courmisch>
you're strongly implying it though
<ball>
(or the QEMU guest, rather)
<jrtc27>
why would QEMU discuss something that's not specific to QEMU?
<jrtc27>
it just does what the world expect
<jrtc27>
*s
levitating_ has quit [Ping timeout: 246 seconds]
<jrtc27>
the (implicit?) contract between SBI and the next stage (U-Boot, EDK2 or a kernel) is that satp.mode is bare
<dhoffman>
SATP is written to not be bare by the Linux kernel shortly after boot
<jrtc27>
and the comments tell you what's going on, no?
<palmer>
dhoffman: ya, it's pretty wacky. Is there something specific you're trying to do? That might be a bit more productive that trying to talk in the abatract
<dhoffman>
my core question is how does the machine recover from an instruction page fault if the STVEC itself is a faulting virtual address
<jrtc27>
STVEC isn't faulting
<jrtc27>
the next PC is
<jrtc27>
potentially
<dhoffman>
palmer: i'm trying to make a minimal RISC-V that can boot linux for some dynamic analysis tools i'm creating
<courmisch>
was that deemed simpler than the two-stage approach on Arm or is there another reason to do it that way?
<jrtc27>
if the configured page tables are such that VA == PA for that page, then the next PC == stvec.base
<ball>
I would like to have a minimal RISC-V vm to start testing it with.
<dhoffman>
VA is not PA AFAICT. it is NULL and the page is marked invalid
<gurki>
dhoffman: what does "make" mean for you?
<gurki>
an emulation model? a fpga implementation? an asic?
<jrtc27>
if the configured page tables are such that VA != PA for that page, then the next PC != stvec.base, and the next PC will fail to translate, causing a trap
<dhoffman>
emulation model
levitating has joined #riscv
<jrtc27>
which will then put stvec.base in PC in the trap handler, which is a valid address, because that's how the page table was set up
<jrtc27>
*for the trap handler
levitating__ has quit [Read error: Connection reset by peer]
<palmer>
dhoffman: I'd just emulate M mode and run the same boot images that QEMU uses for the virt machines. At least that way you have a reference implementation, and it's about as simple as boot is going to get
<ball>
Can qemu emulate a 32-bit RISC-V board?
<palmer>
Ya, just use a 32-bit QEMU ;)
<ball>
Hmm... ok.
<dhoffman>
let me dust off my notes
<dhoffman>
jrtc27: is STVEC interpreted as a physical or virtual address?
mlw has joined #riscv
lemoniter has quit [Quit: lemoniter]
coldfeet has joined #riscv
<dhoffman>
I don't understand how STVEC can't be faulting if the root page of the MMU is not marked valid. SATP.BASE is written as 0x80462 -> address 0x80462000 and the value stored there is all zeroes
<dhoffman>
oh is it interpreted as bare still because the act of writing the SATP (which enables it) is causing an exception
<heat>
stvec is a virtual address
rattlesnake has joined #riscv
<jrtc27>
satp has a physical address
<jrtc27>
stvec has a virtual address
<dhoffman>
that makes sense
<jrtc27>
the "root page" is an entire page
<jrtc27>
ie 4k
<jrtc27>
are you sure it's 4k of zeroes
<jrtc27>
or just that the first word is zero
<dhoffman>
hmm yea i knew it would be something silly like that
<dhoffman>
that's probably it
Isaac_S has quit [Quit: Client closed]
ja_02 has joined #riscv
<dhoffman>
there are some values at the end, but if the address being translated is 0x800000XX, then the first PTE of the root table should be valid because the vpn[4] is 0 and a + va.vpn[4] * PTE_SIZE is a, right?
sakman has quit [Ping timeout: 260 seconds]
sakman has joined #riscv
felixonmars has quit [Remote host closed the connection]
felixonmars has joined #riscv
aredridel has quit [Read error: Connection reset by peer]
<jrtc27>
that's the physical address the kernel was loaded at
<jrtc27>
which becomes the virtual address when translation is enabled
<jrtc27>
and, in this case, isn't the same, so it faults
<jrtc27>
which means the core traps to stvec's virtual address
<jrtc27>
which isn't 0x800000XX
<jrtc27>
and instead should line up with those "values at the end" when translated
<dhoffman>
does it interpret the leadning 0xFFFFFFFF caused by the SXL sign-extension in the memory translation?
<jrtc27>
I don't understand the question
<jrtc27>
stvec has a value, that value is a virtual address, and that is what's translated
<jrtc27>
in its entirety, as-is
<dhoffman>
the 3.1.6.2 section (Base ISA Control in `mstatus` Register) part of the spec states that "pc bits above XLEN are ignored". I'm guessing this only applies to CPU operations and the MMU takes in the full value?
Narrat has quit [Quit: They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.]
<dhoffman>
awesome that solved it
<jrtc27>
that's only relevant if your implementation supports multiple XLEN
<jrtc27>
memory translation happens in S-mode, so it will take whatever value S-mode architecturally sees
<jrtc27>
what M-mode's XLEN is isn't relevant
levitating has quit [Ping timeout: 244 seconds]
<dhoffman>
the section I quoted stated XLEN generically for M, S, and U mode
hightower2 has quit [Remote host closed the connection]
<dhoffman>
i think i understand it now: the PC values are always stored sign extended, but they aren't ignored for MMU translation (but are normally ignored for CPU operations)
levitating has joined #riscv
felixonmars_ has joined #riscv
cleger_ has joined #riscv
test925 has joined #riscv
Andre_Z has joined #riscv
sakman_ has joined #riscv
hightower2 has joined #riscv
sumoon_ has joined #riscv
raghavgururajan_ has joined #riscv
nathanchance_ has joined #riscv
mturquette_ has joined #riscv
benh_ has joined #riscv
hightower2 has quit [Remote host closed the connection]
zx2c4_ has joined #riscv
pavelow_ has joined #riscv
octav1a has joined #riscv
unlord_ has joined #riscv
jedix_ has joined #riscv
mlw_ has joined #riscv
vimer_ has joined #riscv
cheapie_ has joined #riscv
nathanchance has quit [Ping timeout: 246 seconds]
raghavgururajan has quit [Ping timeout: 246 seconds]
felixonmars has quit [Ping timeout: 246 seconds]
zx2c4 has quit [Ping timeout: 246 seconds]
mturquette has quit [Ping timeout: 246 seconds]
sakman has quit [Ping timeout: 246 seconds]
unlord has quit [Ping timeout: 246 seconds]
sumoon has quit [Ping timeout: 246 seconds]
jedix has quit [Ping timeout: 246 seconds]
cleger has quit [Ping timeout: 246 seconds]
mlw has quit [Ping timeout: 246 seconds]
vimer has quit [Ping timeout: 246 seconds]
test924 has quit [Ping timeout: 246 seconds]
benh has quit [Ping timeout: 246 seconds]
Sharktavia has quit [Ping timeout: 246 seconds]
pavelow has quit [Ping timeout: 246 seconds]
cheapie has quit [Ping timeout: 246 seconds]
paddymahoney has quit [Ping timeout: 246 seconds]
nathanchance_ is now known as nathanchance
mturquette_ is now known as mturquette
zx2c4_ is now known as zx2c4
raghavgururajan_ is now known as raghavgururajan
sumoon_ is now known as sumoon
sajattack has quit [Ping timeout: 252 seconds]
cheapie_ is now known as cheapie
X-Scale has quit [Quit: Client closed]
atka has quit [Quit: WeeChat 4.4.1]
sajattack has joined #riscv
hexdump0815 has quit [Quit: WeeChat 3.8]
hightower2 has joined #riscv
paddymahoney has joined #riscv
felixonmars_ is now known as felixonmars
ldevulder has quit [Quit: Leaving]
sajattack has quit [Ping timeout: 246 seconds]
paddymahoney has quit [Ping timeout: 246 seconds]
cleger_ has quit [Ping timeout: 272 seconds]
sajattack has joined #riscv
Andre_Z has quit [Quit: Leaving.]
wingsorc has quit [Quit: Leaving]
levitating has quit [Read error: Connection reset by peer]
levitating has joined #riscv
coldfeet has quit [Quit: leaving]
paddymahoney has joined #riscv
octav1a is now known as Sharktavia
atka has joined #riscv
jobol has quit [Quit: Leaving]
Tenkawa has joined #riscv
craigo has quit [Quit: Leaving]
levitating has quit [Read error: Connection reset by peer]
levitating has joined #riscv
felixonmars has quit [Read error: Connection reset by peer]
felixonmars has joined #riscv
heat_ has joined #riscv
heat has quit [Ping timeout: 252 seconds]
naoki has joined #riscv
heat_ has quit [Remote host closed the connection]