In D43452#1055467, @br wrote:Hi Himanshu what is status of this? could you regenerate for the latest HEAD ?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Mon, Sep 23
Mon, Sep 23
Sep 4 2024
Sep 4 2024
Aug 14 2024
Aug 14 2024
himanshu_thechauhan.dev added a comment to D43452: [RFC] riscv: Introduce support for Incoming MSI Controller (IMSIC).
Aug 13 2024
Aug 13 2024
Hi Himanshu what is status of this? could you regenerate for the latest HEAD ?
Jun 17 2024
Jun 17 2024
Feb 14 2024
Feb 14 2024
Feb 12 2024
Feb 12 2024
himanshu_thechauhan.dev updated the diff for D43293: RISCV: Introduce support for APLIC interrupt controller.
Reworked APLIC_IDC_REG as asked
Feb 3 2024
Feb 3 2024
himanshu_thechauhan.dev added inline comments to D43293: RISCV: Introduce support for APLIC interrupt controller.
Feb 2 2024
Feb 2 2024
Feb 1 2024
Feb 1 2024
himanshu_thechauhan.dev updated the diff for D43293: RISCV: Introduce support for APLIC interrupt controller.
Sorry for the mess up in versions in comments. Last patch was v9, as per my local branches. This one is v10.
himanshu_thechauhan.dev updated the diff for D43293: RISCV: Introduce support for APLIC interrupt controller.
himanshu_thechauhan.dev updated the diff for D43293: RISCV: Introduce support for APLIC interrupt controller.
Changes in v10:
- Save hart indices from FDT and use them to create target value
Jan 31 2024
Jan 31 2024
LGTM!
Jan 28 2024
Jan 28 2024
himanshu_thechauhan.dev added a comment to D43293: RISCV: Introduce support for APLIC interrupt controller.
ping.
Jan 25 2024
Jan 25 2024
himanshu_thechauhan.dev updated the diff for D43293: RISCV: Introduce support for APLIC interrupt controller.
After Convert local interrupt controller to a newbus PIC, commit rebase is required.
Jan 23 2024
Jan 23 2024
himanshu_thechauhan.dev updated the diff for D43293: RISCV: Introduce support for APLIC interrupt controller.
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.
himanshu_thechauhan.dev added a comment to D43293: RISCV: Introduce support for APLIC interrupt controller.
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
Jan 19 2024
himanshu_thechauhan.dev updated the diff for D43293: RISCV: Introduce support for APLIC interrupt controller.
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
himanshu_thechauhan.dev added a comment to D43293: RISCV: Introduce support for APLIC interrupt controller.
@jrtc27 Thanks for your review! I have taken care of your comments. Patch will follow shortly.
Jan 18 2024
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
Jan 17 2024
himanshu_thechauhan.dev added a comment to D43293: RISCV: Introduce support for APLIC interrupt controller.
@mhorne That's great! Thanks for all your time and guidance! I really appreciate it!
Jan 16 2024
Jan 16 2024
I am happy with it, and did some testing locally. Rebinding interrupts seems to work as expected.
himanshu_thechauhan.dev updated the diff for D43293: RISCV: Introduce support for APLIC interrupt controller.
changes in v6:
- Fixed wrong sizing of isrcs
- Fixed indentation of goto label
himanshu_thechauhan.dev added inline comments to D43293: RISCV: Introduce support for APLIC interrupt controller.
Jan 15 2024
Jan 15 2024
This looks pretty good, with one remaining issue that I see.
Jan 14 2024
Jan 14 2024
himanshu_thechauhan.dev updated the test plan for D43452: [RFC] riscv: Introduce support for Incoming MSI Controller (IMSIC).
Jan 10 2024
Jan 10 2024
himanshu_thechauhan.dev updated the diff for D43293: RISCV: Introduce support for APLIC interrupt controller.
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
himanshu_thechauhan.dev added a comment to D43293: RISCV: Introduce support for APLIC interrupt controller.
@mhorne Thanks for the review! I have taken care of your comments. Will be posting new patch shortly.
Jan 9 2024
Jan 9 2024
Thanks a lot for submitting this!
Jan 7 2024
Jan 7 2024
jrtc27 added reviewers for D43293: RISCV: Introduce support for APLIC interrupt controller: jrtc27, riscv.
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
Jan 6 2024
himanshu_thechauhan.dev updated the diff for D43293: RISCV: Introduce support for APLIC interrupt controller.
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
Jan 4 2024
himanshu_thechauhan.dev updated the diff for D43293: RISCV: Introduce support for APLIC interrupt controller.
v3 changes:
- Removed duplicated defines
- Added comments to some of the structures and defines
- Cosmetic changes.
himanshu_thechauhan.dev added inline comments to D43293: RISCV: Introduce support for APLIC interrupt controller.
tools/build/checkstyle9.pl will check most common style issues
himanshu_thechauhan.dev updated the diff for D43293: RISCV: Introduce support for APLIC interrupt controller.
Took care of formatting and other comments.
himanshu_thechauhan.dev added inline comments to D43293: RISCV: Introduce support for APLIC interrupt controller.
himanshu_thechauhan.dev added inline comments to D43293: RISCV: Introduce support for APLIC interrupt controller.
Jan 3 2024
Jan 3 2024
himanshu_thechauhan.dev added a comment to D43293: RISCV: Introduce support for APLIC interrupt controller.
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?
himanshu_thechauhan.dev added inline comments to D43293: RISCV: Introduce support for APLIC interrupt controller.
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?
himanshu_thechauhan.dev added a comment to D43293: RISCV: Introduce support for APLIC interrupt controller.
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!
himanshu_thechauhan.dev added a reviewer for D43293: RISCV: Introduce support for APLIC interrupt controller: mhorne.
himanshu_thechauhan.dev requested review of D43293: RISCV: Introduce support for APLIC interrupt controller.
Jul 4 2023
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
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
Jun 27 2023
Address comments, fix undefined behavior when working with potentially unaligned pointers.
Jun 25 2023
Jun 25 2023
May 31 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
May 30 2023
Check for the function prologue.
May 26 2023
May 26 2023
Do not use kinst_memcpy outside of probe context.
Use kinst_memcpy() and also add kinst_md_excluded().
May 25 2023
May 25 2023
Address comments.
May 24 2023
May 24 2023