Reworked APLIC_IDC_REG as asked
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 14 2024
Feb 12 2024
Feb 3 2024
Feb 2 2024
Feb 1 2024
Sorry for the mess up in versions in comments. Last patch was v9, as per my local branches. This one is v10.
Changes in v10:
- Save hart indices from FDT and use them to create target value
Jan 31 2024
LGTM!
Jan 28 2024
ping.
Jan 25 2024
After Convert local interrupt controller to a newbus PIC, commit rebase is required.
Jan 23 2024
Changes in v7:
- Keep per-cpu IDC offsets after reading interrupts-extended property
- Accessing IDC is via the stored per-CPU IDC offsets
- Remove cleanup after failure in *_attach function (like other drivers)
- Added aplic.c in files.riscv alphabetically
In D43293#993161, @himanshu_thechauhan.dev wrote:In D43293#993109, @jrtc27 wrote:In D43293#991986, @himanshu_thechauhan.dev wrote:@jrtc27 Thanks for your review! I have taken care of your comments. Patch will follow shortly.
Unless I'm mistaken you still use the hartid to index the APLIC, not the APLIC's hart indexes. You need to actually record, and later use, the index <-> cpu mapping when iterating over interrupts-extended.
Whatever hartid is read from the FDT, its logical CPU is kept in target_cpu cpuset. We already, in a way, keep that mapping. When the interrupts are bound, the logical CPU from target_cpu points to the required hart. There is no need to keep separate mapping.
In D43293#993109, @jrtc27 wrote:In D43293#991986, @himanshu_thechauhan.dev wrote:@jrtc27 Thanks for your review! I have taken care of your comments. Patch will follow shortly.
Unless I'm mistaken you still use the hartid to index the APLIC, not the APLIC's hart indexes. You need to actually record, and later use, the index <-> cpu mapping when iterating over interrupts-extended.
In D43293#991986, @himanshu_thechauhan.dev wrote:@jrtc27 Thanks for your review! I have taken care of your comments. Patch will follow shortly.
Jan 19 2024
Changes in v6:
- Added verification of harts that can take interrupt using "interrupts-extended" property of FDT.
- Added target_cpu cpuset which contains the bit map of logical cpus that can take interrupts.
- During binding of the irqs, the cpus from target_cpu cpuset is used.
- Handled failure case and deregister ircs.
- Took care of comments regarding the brackets.
- Added a macro APLIC_IDC to give offset of a given hart.
- Removed return of FILTER_STRAY when IRQ is 0, added a KASSERT instead.
- Use of DEFINE_CLASS_0
@jrtc27 Thanks for your review! I have taken care of your comments. Patch will follow shortly.
Jan 18 2024
In D43293#991694, @jrtc27 wrote:Also this doesn't properly deal with the interrupts-extended property. I believe that, like the PLIC, you need to iterate over its cells to figure out the mapping between architectural hart ID and APLIC hart index, since they are two independent schemes.
With apologies for the delay:
Jan 17 2024
@mhorne That's great! Thanks for all your time and guidance! I really appreciate it!
Jan 16 2024
I am happy with it, and did some testing locally. Rebinding interrupts seems to work as expected.
changes in v6:
- Fixed wrong sizing of isrcs
- Fixed indentation of goto label
Jan 15 2024
This looks pretty good, with one remaining issue that I see.
Jan 14 2024
Jan 10 2024
Changes in v5:
- Use hartid instead of logical cpu when programming APLIC registers
- Add defines for some hard coded numbers
- Check for "msi-parent" property during attach and fail if found
- Removed the IDC structure and added defines for the IDC register offsets and calculations
- Removed reuse of local variables
- Removed unused function and structures
- Removed "all rights reserved" from copyright comment
- Removed ambiguity of cpu vs hartid
@mhorne Thanks for the review! I have taken care of your comments. Will be posting new patch shortly.
Jan 9 2024
Thanks a lot for submitting this!
Jan 7 2024
FYI I intend to give this a more proper review this week, now that I've returned from my travels over the holidays
Jan 6 2024
v4
- Fixed bug
- Uniprocessor boot used to hang.
- Now it is tested from 1 CPU to 16 CPUs
- virtio block dev is tested
- virtionet is tested
Jan 4 2024
v3 changes:
- Removed duplicated defines
- Added comments to some of the structures and defines
- Cosmetic changes.
tools/build/checkstyle9.pl will check most common style issues
Took care of formatting and other comments.
Jan 3 2024
In D43293#986788, @jrtc27 wrote:I have a related series ending in https://reviews.freebsd.org/D35901 to get back to that should make having direct and IMSIC APLIC support less messy due to changing what the root PIC is. That shouldn’t block this patch as it’s (presumably) just similar tweaks to the normal PLIC, but for IMSIC support it’s probably worth me pushing forward on that before you get too far with it?
I have a related series ending in https://reviews.freebsd.org/D35901 to get back to that should make having direct and IMSIC APLIC support less messy due to changing what the root PIC is. That shouldn’t block this patch as it’s (presumably) just similar tweaks to the normal PLIC, but for IMSIC support it’s probably worth me pushing forward on that before you get too far with it?
Time to teach my emacs the style(9) KNF. I will take care of these suggestions. Thanks!
Note that some lines don't fit 80 chars per style (9) and some have too much whitespace after wrap.
Interesting!
Jul 4 2023
In D39884#930242, @jrtc27 wrote:In D39884#930234, @christos wrote:In D39884#930225, @mhorne wrote:In D39884#928340, @markj wrote:This provider can trigger what appears to be a QEMU/TCG bug. The test case:
- boot a riscv VM with more than one vCPU
- run dtrace -q -n 'kinst::riscv_cpu_intr:', i.e., trace all instructions in riscv_cpu_intr()
Seems I was a bit slow to report my findings, but I did observe some of the same kinds of panics on real hardware that I saw in QEMU. I will update to the committed version and provide a more detailed answer of what is still not working.
Can you recompile kinst with this patch applied? https://reviews.freebsd.org/P592
If we run it with a single trampoline per page, the crashes seem to go away.Is it just a case of needing to smp_rendezvous a fence_i since it's not broadcast by the hardware like on arm64?
In D39884#930242, @jrtc27 wrote:Is it just a case of needing to smp_rendezvous a fence_i since it's not broadcast by the hardware like on arm64?
In D39884#930234, @christos wrote:In D39884#930225, @mhorne wrote:In D39884#928340, @markj wrote:This provider can trigger what appears to be a QEMU/TCG bug. The test case:
- boot a riscv VM with more than one vCPU
- run dtrace -q -n 'kinst::riscv_cpu_intr:', i.e., trace all instructions in riscv_cpu_intr()
Seems I was a bit slow to report my findings, but I did observe some of the same kinds of panics on real hardware that I saw in QEMU. I will update to the committed version and provide a more detailed answer of what is still not working.
Can you recompile kinst with this patch applied? https://reviews.freebsd.org/P592
If we run it with a single trampoline per page, the crashes seem to go away.
In D39884#930225, @mhorne wrote:In D39884#928340, @markj wrote:This provider can trigger what appears to be a QEMU/TCG bug. The test case:
- boot a riscv VM with more than one vCPU
- run dtrace -q -n 'kinst::riscv_cpu_intr:', i.e., trace all instructions in riscv_cpu_intr()
Seems I was a bit slow to report my findings, but I did observe some of the same kinds of panics on real hardware that I saw in QEMU. I will update to the committed version and provide a more detailed answer of what is still not working.
In D39884#930225, @mhorne wrote:In D39884#928340, @markj wrote:This provider can trigger what appears to be a QEMU/TCG bug. The test case:
- boot a riscv VM with more than one vCPU
- run dtrace -q -n 'kinst::riscv_cpu_intr:', i.e., trace all instructions in riscv_cpu_intr()
Seems I was a bit slow to report my findings, but I did observe some of the same kinds of panics on real hardware that I saw in QEMU. I will update to the committed version and provide a more detailed answer of what is still not working.
In D39884#928340, @markj wrote:This provider can trigger what appears to be a QEMU/TCG bug. The test case:
- boot a riscv VM with more than one vCPU
- run dtrace -q -n 'kinst::riscv_cpu_intr:', i.e., trace all instructions in riscv_cpu_intr()
Retain CDDL license.
Restore original trampoline size.
Address comments, update LICENSE headers, split some changes to other PRs.
Jun 28 2023
This provider can trigger what appears to be a QEMU/TCG bug. The test case:
- boot a riscv VM with more than one vCPU
- run dtrace -q -n 'kinst::riscv_cpu_intr:', i.e., trace all instructions in riscv_cpu_intr()
Jun 27 2023
Address comments, fix undefined behavior when working with potentially unaligned pointers.
Jun 25 2023
May 31 2023
Address comments.
In D39884#918563, @markj wrote:I've been doing some testing in QEMU again. I'm occasionally able to trigger random "impossible" panics by running dtrace -n 'kinst::vm_fault:' -q & and running various programs in the foreground. top(1), running tests, etc.. It's rather difficult to reproduce though. :(
I've been doing some testing in QEMU again. I'm occasionally able to trigger random "impossible" panics by running dtrace -n 'kinst::vm_fault:' -q & and running various programs in the foreground. top(1), running tests, etc.. It's rather difficult to reproduce though. :(
May 30 2023
Check for the function prologue.
May 26 2023
Do not use kinst_memcpy outside of probe context.
Use kinst_memcpy() and also add kinst_md_excluded().
May 25 2023
Address comments.
May 24 2023
May 23 2023
Update tramp fill.
May 22 2023
Approved
May 15 2023
Fix LL/SC exclusion algorithm.