Update to xv6: since Jul 10, 2024 the code is changed so that supervisor gets the timer interrupts delegated. This was enabled in riscv 1.10 and in qemu Version 7.2.
Hi Professor, Your xv6 video lectures have been brilliant and helped me understand the operating system at a much deeper level. Would it be possible for you to also release the drawings/notes that you used in the videos? Any format like PDF or PPT would be greatly appreciated. Having access to those supplementary materials would further enhance my learning experience.
Very nice video, made my understanding of both xv6 and risc-v more in depth. But I still have something that I don't understand, risc-v designed the supervisor timmer intterupt in the scause, and also reserved a bit belonging to it in the sie register, but why can't the timmer intterupt directly delegate to the supervisor mode?
Great Video. I'm using a sifive FE310-G002 and it generates a trap when I force a misaligned load. The ESP32C3 handles the misaligned load at hardware level (no trap). I found that the linux kernel handles these misaligned loads (and stores) in the code (arch/riscv/kernel/traps_misaligned.c) so I'm trying to port this to the FE310-G002. The part I find interesting is that when you call mret, it does restore the PC value from mepc, which I found incorrect since it's the instruction that triggered the trap so it would be returning there.. and with the debugger I can see it sets the PC to that value. IF I advance mepc (in my case by 2 since the instruction that triggers the trap is a compressed one) it moves forward, otherwise, it jumps back to the trap-generating instruction and goes back into the trap handler for ever.
Yes, I understand. You need to advance mepc past the instruction which caused the trap. You might ask whey the hardware doesn’t simply advance mepc. For some traps (such as those caused by a page fault), the kernel will need to take action (such as read a page from disk in to memory, or update a page table entry). Then, we need to return to the instruction that caused the problem and re-execute it. After the kernel has “fixed” the problem, the instruction should execute without a trap on the second attempt. To allow the same instruction to be re-executed, the PC must not be advanced.
You mentioned several times in these videos that you can't delegate timer interrupts from M mode to S mode. I looked over the privilege spec and didn't see anything mentioned about that. Is that a bug in the implementation of the virtual hardware in qemu? It sounds like that was discovered by accident, rather than something that exists in the spec, but I wanted to make sure.
I'm pretty sure you can by now. If you use OpenSBI, then you don't have to write your own M-mode code to handle timers, instead you can ecall to M-mode and then set a timer that will trap to S-mode. I'm assuming it may have been a bug or unimplemented when the code was written. Just make sure you have the STIE bit enabled in the sie CSR.
Never seen such a great and emphasizing video before. Keep goin! Loved it!
Update to xv6: since Jul 10, 2024 the code is changed so that supervisor gets the timer interrupts delegated. This was enabled in riscv 1.10 and in qemu Version 7.2.
Amazing content, thanks, best OS series.
Hi Professor,
Your xv6 video lectures have been brilliant and helped me understand the operating system at a much deeper level. Would it be possible for you to also release the drawings/notes that you used in the videos? Any format like PDF or PPT would be greatly appreciated. Having access to those supplementary materials would further enhance my learning experience.
Very nice video, made my understanding of both xv6 and risc-v more in depth. But I still have something that I don't understand, risc-v designed the supervisor timmer intterupt in the scause, and also reserved a bit belonging to it in the sie register, but why can't the timmer intterupt directly delegate to the supervisor mode?
Great Video. I'm using a sifive FE310-G002 and it generates a trap when I force a misaligned load. The ESP32C3 handles the misaligned load at hardware level (no trap). I found that the linux kernel handles these misaligned loads (and stores) in the code (arch/riscv/kernel/traps_misaligned.c) so I'm trying to port this to the FE310-G002. The part I find interesting is that when you call mret, it does restore the PC value from mepc, which I found incorrect since it's the instruction that triggered the trap so it would be returning there.. and with the debugger I can see it sets the PC to that value. IF I advance mepc (in my case by 2 since the instruction that triggers the trap is a compressed one) it moves forward, otherwise, it jumps back to the trap-generating instruction and goes back into the trap handler for ever.
Yes, I understand. You need to advance mepc past the instruction which caused the trap. You might ask whey the hardware doesn’t simply advance mepc. For some traps (such as those caused by a page fault), the kernel will need to take action (such as read a page from disk in to memory, or update a page table entry). Then, we need to return to the instruction that caused the problem and re-execute it. After the kernel has “fixed” the problem, the instruction should execute without a trap on the second attempt. To allow the same instruction to be re-executed, the PC must not be advanced.
You mentioned several times in these videos that you can't delegate timer interrupts from M mode to S mode. I looked over the privilege spec and didn't see anything mentioned about that. Is that a bug in the implementation of the virtual hardware in qemu? It sounds like that was discovered by accident, rather than something that exists in the spec, but I wanted to make sure.
I'm pretty sure you can by now. If you use OpenSBI, then you don't have to write your own M-mode code to handle timers, instead you can ecall to M-mode and then set a timer that will trap to S-mode. I'm assuming it may have been a bug or unimplemented when the code was written. Just make sure you have the STIE bit enabled in the sie CSR.
Not sure when kernelvec or uservec written to stvec