Page MenuHomeFreeBSD

jrtc27 (Jessica Clarke)
User

Projects

User Details

User Since
Jul 4 2018, 7:23 PM (115 w, 3 d)

Recent Activity

Fri, Sep 18

jrtc27 added a comment to D26471: Build debug kernels with -O2..
In D26471#588937, @imp wrote:

Will this screw up the tracebacks? One of the reason that I've compiled at lower O levels is to not have @#^#$Y up DEBUG kernels...

Fri, Sep 18, 7:48 PM
jrtc27 added inline comments to D26471: Build debug kernels with -O2..
Fri, Sep 18, 3:14 PM
jrtc27 added a comment to D26473: Significantly speed up libthr/mutex_test and make more reliable.

These are in contrib/netbsd-tests; will you be submitting this upstream? I note that our vendor copy is ancient; mutex6 was deleted upstream in December 2017, and the workaround for PR 44387 on PowerPC removed in March 2017.

Fri, Sep 18, 10:47 AM

Thu, Sep 10

jrtc27 added a comment to D26389: dtrace: Fix fbt return probes on RISC-V.
In D26389#586875, @kp wrote:
In D26389#586864, @kp wrote:

That's true. I don't think we make the full trapframe available in probe context (e.g., using a thread field, so it's accessible via curthread), but that would also make the full return value accessible.

I'm not very familiar with the internals of DTrace, but given that we don't pass the trapframe to dtrace_probe() I expect that to be a fairly invasive change.

Why's that relevant? The only thing that matters is the call to dtrace_invop, which passes the trapframe everywhere except i386 (I think amd64 even passes it from glancing at the assembly). And everywhere except x86 is getting that argument out of the trapframe in the caller, which is just silly.

I'm thinking about how we'd get the trapframe to the userspace dtrace process, to allow the script to extract information form a0/a1 in case there's relevant information there. That flow passes through dtrace_probe().

An alternative might be to pass a1 (as opposed to the 0 we pass now) in the return dtrace_probe(). That'll let scripts access it as arg2. That'd be different from all other platforms, but arg2 is not defined for the return probe anyway.

Sounds reasonable to me. For this diff I guess we just want to change fbt_invop() to fetch the return value out of the trap frame instead of using the extra argument from dtrace_invop().

I have a weak objection to that, as that's different from what other platforms do. x86 also obtains the return value as the argument to fbt_invop().

Yeah, but the other platforms only do that because that's what x86 does, which is special. You can see that from the fact that the dtrace_invop _prototype_ has the last argument called eax on all architectures.

Sure. I'll post an update in a few minutes. I'm inclined to keep the change in riscv/dtrace_subr.c, because passing the sepc isn't useful either.

Thu, Sep 10, 3:43 PM
jrtc27 added a comment to D26389: dtrace: Fix fbt return probes on RISC-V.
In D26389#586881, @kp wrote:
In D26389#586875, @kp wrote:

An alternative might be to pass a1 (as opposed to the 0 we pass now) in the return dtrace_probe(). That'll let scripts access it as arg2. That'd be different from all other platforms, but arg2 is not defined for the return probe anyway.

So this:

diff --git a/sys/cddl/dev/fbt/riscv/fbt_isa.c b/sys/cddl/dev/fbt/riscv/fbt_isa.c
index 92a0397cefb..406fcd3f9be 100644
--- a/sys/cddl/dev/fbt/riscv/fbt_isa.c
+++ b/sys/cddl/dev/fbt/riscv/fbt_isa.c
@@ -65,7 +65,7 @@ fbt_invop(uintptr_t addr, struct trapframe *frame, uintptr_t rval)
                                    frame->tf_a[3], frame->tf_a[4]);
                        } else {
                                dtrace_probe(fbt->fbtp_id, fbt->fbtp_roffset,
-                                   frame->tf_a[0], 0, 0, 0);
+                                   frame->tf_a[0], frame->tf_a[1], 0, 0);
                        }

                        cpu->cpu_dtrace_caller = 0;

I'd hate to commit us to supporting this indefinitely across all platforms though.

Thu, Sep 10, 3:40 PM
jrtc27 added a comment to D26389: dtrace: Fix fbt return probes on RISC-V.
In D26389#586864, @kp wrote:

That's true. I don't think we make the full trapframe available in probe context (e.g., using a thread field, so it's accessible via curthread), but that would also make the full return value accessible.

I'm not very familiar with the internals of DTrace, but given that we don't pass the trapframe to dtrace_probe() I expect that to be a fairly invasive change.

Thu, Sep 10, 2:40 PM
jrtc27 added a comment to D26389: dtrace: Fix fbt return probes on RISC-V.

The original implementation is copied from AArch64.

The AArch64 implementation looks wrong to me. It only handles entry probes.

I'm not convinced this change is correct; RISC-V returns small structs in a0/a1, so this will miss half of such structs.

DTrace doesn't really handle function arguments or return values larger than the register width, unfortunately. The assumption that argument and return types are either pointers or base integer types appears in several places.

Thu, Sep 10, 1:04 PM
jrtc27 added a comment to D26389: dtrace: Fix fbt return probes on RISC-V.

So, whatever the right way to fix this is, RISC-V, AArch64, Arm and MIPS should all be changed in the same way. PowerPC seems to be as is done in this patch. IMO the eax argument is a waste of time, and it would be far better if the FBT code just looked at the trapframe to get out whatever set of registers it needs; it's clearer, it can get at more than just the one register and it avoids redundancy.

Thu, Sep 10, 1:02 PM
jrtc27 added a comment to D26389: dtrace: Fix fbt return probes on RISC-V.

The original implementation is copied from AArch64. I'm not convinced this change is correct; RISC-V returns small structs in a0/a1, so this will miss half of such structs.

Thu, Sep 10, 12:49 PM

Sat, Sep 5

jrtc27 requested review of D26336: buf_ring: Fix atomics usage and clean up assertions.
Sat, Sep 5, 1:16 PM

Aug 9 2020

jrtc27 requested changes to D26015: Check for invalid pc in unwind_frame.
Aug 9 2020, 4:50 PM

Jul 29 2020

jrtc27 added inline comments to D25867: Correct padding length for RISC-V PCPU data..
Jul 29 2020, 3:00 PM
jrtc27 removed a watcher for riscv: jrtc27.
Jul 29 2020, 3:24 AM
jrtc27 added a member for riscv: jrtc27.
Jul 29 2020, 3:23 AM

Jul 28 2020

jrtc27 added inline comments to D25867: Correct padding length for RISC-V PCPU data..
Jul 28 2020, 6:34 PM
jrtc27 added a comment to D25867: Correct padding length for RISC-V PCPU data..
  1. Can we please properly document where this magic value comes from?
Jul 28 2020, 6:21 PM

Jul 26 2020

jrtc27 committed rS363574: riscv: Include syscon_power device driver in GENERIC kernel config.
riscv: Include syscon_power device driver in GENERIC kernel config
Jul 26 2020, 6:21 PM
jrtc27 closed D25725: riscv: Include syscon_power device driver in GENERIC kernel config.
Jul 26 2020, 6:21 PM
jrtc27 committed rS363573: Add syscon power and reset control device driver.
Add syscon power and reset control device driver
Jul 26 2020, 6:20 PM
jrtc27 closed D25724: Add syscon power and reset control device driver.
Jul 26 2020, 6:20 PM
jrtc27 committed rS363572: loader: Avoid -Wpointer-to-int cast warnings for Arm and RISC-V.
loader: Avoid -Wpointer-to-int cast warnings for Arm and RISC-V
Jul 26 2020, 6:17 PM
jrtc27 closed D25718: loader: Avoid -Wpointer-to-int cast warnings for Arm and RISC-V.
Jul 26 2020, 6:17 PM
jrtc27 committed rS363571: Add Goldfish RTC device driver for RISC-V.
Add Goldfish RTC device driver for RISC-V
Jul 26 2020, 6:15 PM
jrtc27 closed D25717: Add Goldfish RTC device driver for RISC-V.
Jul 26 2020, 6:15 PM

Jul 20 2020

jrtc27 added inline comments to D25725: riscv: Include syscon_power device driver in GENERIC kernel config.
Jul 20 2020, 10:56 PM

Jul 19 2020

jrtc27 requested review of D25725: riscv: Include syscon_power device driver in GENERIC kernel config.
Jul 19 2020, 6:27 PM
jrtc27 requested review of D25724: Add syscon power and reset control device driver.
Jul 19 2020, 6:25 PM

Jul 18 2020

jrtc27 updated the diff for D25718: loader: Avoid -Wpointer-to-int cast warnings for Arm and RISC-V.

Drop explicit (void *) cast. Clang's -pedantic wants it, but GCC's -pedantic complains about the cast itself as function pointer to object pointer casts are an optional extension in ISO C. Since we can't please everyone, go with the least-cluttered option and just drop it. Building FreeBSD with -pedantic is never going to happen anyway.

Jul 18 2020, 6:40 PM
jrtc27 added inline comments to D25718: loader: Avoid -Wpointer-to-int cast warnings for Arm and RISC-V.
Jul 18 2020, 6:36 PM
jrtc27 added inline comments to D25718: loader: Avoid -Wpointer-to-int cast warnings for Arm and RISC-V.
Jul 18 2020, 6:12 PM
jrtc27 added inline comments to D25718: loader: Avoid -Wpointer-to-int cast warnings for Arm and RISC-V.
Jul 18 2020, 5:59 PM
jrtc27 updated the diff for D25717: Add Goldfish RTC device driver for RISC-V.

... back to the right patch

Jul 18 2020, 4:47 PM
jrtc27 updated the diff for D25717: Add Goldfish RTC device driver for RISC-V.

Fixed stray non-breaking space in comment

Jul 18 2020, 4:46 PM
jrtc27 requested review of D25718: loader: Avoid -Wpointer-to-int cast warnings for Arm and RISC-V.
Jul 18 2020, 4:42 PM
jrtc27 requested review of D25717: Add Goldfish RTC device driver for RISC-V.
Jul 18 2020, 4:39 PM

Jul 3 2020

jrtc27 added a comment to D25531: riscv plic: Do not complete interrupts until the interrupt handler has run.

I've re-read the PLIC spec, the discussions here, and did some spelunking in the MI interrupt code. As far as I can see this change is correct.

I will see about getting the PLIC spec clarified in terms of the exact behaviour of claim/complete.

My remaining question is this: if the IP bit is cleared by the claim, and cannot be set again until the completion has been done for that context, then is there any reason to continue clearing/setting the enable bit for the interrupt we are servicing? Doesn't the claim/completion process provide the correct behaviour on its own?

Jul 3 2020, 8:45 PM

Jul 2 2020

jrtc27 added inline comments to D25416: Make access to VirtIO configuration to mips architecture..
Jul 2 2020, 2:48 PM · PowerPC, MIPS
jrtc27 added a comment to D25544: riscv: look for bootargs in FDT.

Also, please avoid filing revisions with CheriBSD tainting the diff; it can be misleading, as well as the fact that we're always a bit behind (and in this case it does matter because of the loader(8) patch landing).

Jul 2 2020, 2:22 AM · riscv
jrtc27 added a comment to D25544: riscv: look for bootargs in FDT.

arm64's parse_fdt_bootargs deals with loader(8) which will normally handle these for us when used, so we need to copy that approach given https://reviews.freebsd.org/D24912 has landed. My guess is the best place for it is parse_metadata around where we currently call init_static_kenv, to match arm64.

Jul 2 2020, 2:21 AM · riscv

Jul 1 2020

jrtc27 added a comment to D25531: riscv plic: Do not complete interrupts until the interrupt handler has run.
In D25531#564563, @jhb wrote:

FWIW, the general strategy on x86 and other platforms is to mask the interrupt in the PIC in the "pre_ithread" hook and later re-enable it in the PIC again in the "post_ithread" hook. Both "pre_ithread" and "post_filter" send an EOI as they are the only ones guaranteed to run synchronously on the CPU which received the interrupt. MSI alleviates the need for masking on most platforms since it is effectively edge triggered so actual level-triggered interrupts are rare on many modern systems. I'm not quite sure how that model translates to the PLIC, but on the surface reading the description of this commit seems to imply it is not doing the same thing at all. The reason we did this on x86 is that the EOI was global and could not be deferred to post_ithread. If you don't have a global EOI but instead are free to get additional interrupts (including additional lower priority interrupts) while the interrupt is not claimed, then I think your commit will work fine. However, if a high priority interrupt (PLIC priority) blocks other interrupts then you are letting that ithread starve the filters, etc. for other devices which is probably not ideal.

That's what the driver is currently doing in plic_pre_ithread and plic_post_ithread. The spec sucks and doesn't really say what claim/complete actually do, but at least the QEMU and Bluespec implementations of the PLIC will clear the IP bit and forbid the IP bit going high until completed, effectively masking the interrupt for _every_ target by masking on the _source_.

Jul 1 2020, 11:07 PM
jrtc27 added a comment to D25531: riscv plic: Do not complete interrupts until the interrupt handler has run.
In D25531#564579, @kp wrote:

That's what the driver is currently doing in plic_pre_ithread and plic_post_ithread. The spec sucks and doesn't really say what claim/complete actually do, but at least the QEMU and Bluespec implementations of the PLIC will clear the IP bit and forbid the IP bit going high until completed, effectively masking the interrupt for _every_ target by masking on the _source_.

That reminds me: the qemu implementation has a bug that means it won't trigger interrupts when we re-enable them, leading to stalls (until you trigger another interrupt, e.g. by sending something on the console).

The following Qemu patch fixes that:

--- hw/riscv/sifive_plic.c.orig	2019-11-14 19:06:20.000000000 +0100
+++ hw/riscv/sifive_plic.c	2020-07-01 15:59:38.882119000 +0200
@@ -290,6 +290,7 @@
             qemu_log("plic: write priority: irq=%d priority=%d\n",
                 irq, plic->source_priority[irq]);
         }
+        sifive_plic_update(plic);
         return;
     } else if (addr >= plic->pending_base && /* 1 bit per source */
                addr < plic->pending_base + (plic->num_sources >> 3))

Ahh, I have experienced this. It might be responsible for the deadlocks @trasz has seen running the test suite in CI. Has this patch been submitted upstream?

Jul 1 2020, 7:21 PM
jrtc27 added a comment to D25531: riscv plic: Do not complete interrupts until the interrupt handler has run.
In D25531#564563, @jhb wrote:

FWIW, the general strategy on x86 and other platforms is to mask the interrupt in the PIC in the "pre_ithread" hook and later re-enable it in the PIC again in the "post_ithread" hook. Both "pre_ithread" and "post_filter" send an EOI as they are the only ones guaranteed to run synchronously on the CPU which received the interrupt. MSI alleviates the need for masking on most platforms since it is effectively edge triggered so actual level-triggered interrupts are rare on many modern systems. I'm not quite sure how that model translates to the PLIC, but on the surface reading the description of this commit seems to imply it is not doing the same thing at all. The reason we did this on x86 is that the EOI was global and could not be deferred to post_ithread. If you don't have a global EOI but instead are free to get additional interrupts (including additional lower priority interrupts) while the interrupt is not claimed, then I think your commit will work fine. However, if a high priority interrupt (PLIC priority) blocks other interrupts then you are letting that ithread starve the filters, etc. for other devices which is probably not ideal.

Jul 1 2020, 6:42 PM
jrtc27 added a comment to D25531: riscv plic: Do not complete interrupts until the interrupt handler has run.

Some more comments:

Jul 1 2020, 1:32 PM
jrtc27 added a comment to D25531: riscv plic: Do not complete interrupts until the interrupt handler has run.

Are there not issues with a device driver disabling interrupts in its handler (either synchronous or asynchronous) for whatever reason and then that being clobbered by the plic_post_filter method? That already happened with pic_post_ithread... But we shouldn't need to disable/enable any more at all? An interrupt is suppressed the entire time we have it claimed, I assume the disable/enable code is there so we don't keep getting interrupts when using an ithread.

Jul 1 2020, 1:10 PM

Jun 26 2020

jrtc27 added inline comments to D25304: Include ABI note tag in shared libraries..
Jun 26 2020, 12:04 PM

Jun 25 2020

jrtc27 added inline comments to D25304: Include ABI note tag in shared libraries..
Jun 25 2020, 11:07 PM

Jun 24 2020

jrtc27 added inline comments to D25416: Make access to VirtIO configuration to mips architecture..
Jun 24 2020, 1:39 PM · PowerPC, MIPS

Jun 23 2020

jrtc27 added inline comments to D25419: Enable long double tests on RISC-V.
Jun 23 2020, 8:43 PM
jrtc27 closed D25131: virtio_mmio: Negotiate the upper half of the feature bits too.
Jun 23 2020, 3:26 AM
jrtc27 requested review of D24827: riscv: Fix pmap_protect for superpages.
Jun 23 2020, 3:23 AM
jrtc27 requested review of D25131: virtio_mmio: Negotiate the upper half of the feature bits too.
Jun 23 2020, 3:21 AM
jrtc27 requested review of D24827: riscv: Fix pmap_protect for superpages.
Jun 23 2020, 3:17 AM
jrtc27 closed D24827: riscv: Fix pmap_protect for superpages.
Jun 23 2020, 3:17 AM

Jun 19 2020

jrtc27 added a comment to D25317: Include TMPFS in all the GENERIC kernel configs.

Why are we doing this for GENERIC? No other architecture does so, and the only differences between them for GENERIC should be genuinely architecture-specific things, which TMPFS is not. If you want it for MFSROOT kernels, limit it to those. GENERIC is supposed to pick it up as a module just like everything else not required during earlyish boot.

arm/GENERIC has include "std.armv7" which enables TMPFS

Jun 19 2020, 12:44 AM
jrtc27 added inline comments to D25217: Include virtio support in std.MALTA.
Jun 19 2020, 12:43 AM

Jun 18 2020

jrtc27 added a comment to D24912: Handle load from loader(8).

I don't know the details of loader, but this looks like a much better approach and doesn't perturb the SBI paths much so I'm happy.

Jun 18 2020, 8:50 PM
jrtc27 requested changes to D25317: Include TMPFS in all the GENERIC kernel configs.

Why are we doing this for GENERIC? No other architecture does so, and the only differences between them for GENERIC should be genuinely architecture-specific things, which TMPFS is not. If you want it for MFSROOT kernels, limit it to those. GENERIC is supposed to pick it up as a module just like everything else not required during earlyish boot.

Jun 18 2020, 10:35 AM

Jun 17 2020

jrtc27 added a comment to D25304: Include ABI note tag in shared libraries..
In D25304#558060, @kib wrote:

I wonder if it makes sense to use separate compilation for all .S/.s files and glue them together with ld -r for crti.o instead of includes ?

Jun 17 2020, 5:18 AM

Jun 14 2020

jrtc27 committed rS362186: vtnet: Fix regression introduced in r361944.
vtnet: Fix regression introduced in r361944
Jun 14 2020, 10:39 PM

Jun 12 2020

jrtc27 added inline comments to D25210: llvm: Default to -mno-relax.
Jun 12 2020, 8:07 PM
jrtc27 added a comment to D25210: llvm: Default to -mno-relax.

Patching the in-tree Clang to default to -mno-relax for FreeBSD might make sense. But out-of-tree can be used with BFD so that's not upstreamable.

Jun 12 2020, 4:32 PM
jrtc27 added a comment to D25210: llvm: Default to -mno-relax.
In D25210#556611, @kp wrote:

I run into this trying to build ports, but this is the simplest reproduction case:

# cat t.c
#include <stdio.h>

int main (void)
{
        printf("Hello\n");
        return (0);
}
root@pkgbuilder:~ # cc t.c -o t
ld: error: t.c:(.text+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax
cc: error: linker command failed with exit code 1 (use -v to see invocation)
root@pkgbuilder:~ # cc -mno-relax t.c -o t
root@pkgbuilder:~ # ./t
Hello
Jun 12 2020, 4:24 PM
jrtc27 added a comment to D25210: llvm: Default to -mno-relax.

Agreed; this is too big a hammer (and one day LLD will gain the ability to do the relaxations too; I posted a proof-of-concept for R_RISCV_ALIGN a couple of months ago and there was some activity from others).

Jun 12 2020, 4:09 PM

Jun 10 2020

jrtc27 added inline comments to D25211: Remove the sed hack for ABI tag notes..
Jun 10 2020, 4:49 PM
jrtc27 added inline comments to D25211: Remove the sed hack for ABI tag notes..
Jun 10 2020, 4:39 PM
jrtc27 added inline comments to D25211: Remove the sed hack for ABI tag notes..
Jun 10 2020, 4:31 PM

Jun 8 2020

jrtc27 committed rS361944: virtio: Support non-legacy network device and queue.
virtio: Support non-legacy network device and queue
Jun 8 2020, 9:51 PM
jrtc27 closed D25132: virtio: Support non-legacy network device and queue.
Jun 8 2020, 9:51 PM
jrtc27 committed rS361943: virtio_mmio: Negotiate the upper half of the feature bits too.
virtio_mmio: Negotiate the upper half of the feature bits too
Jun 8 2020, 9:50 PM
jrtc27 committed rS361932: riscv: Use SBI shutdown call to implement RB_POWEROFF.
riscv: Use SBI shutdown call to implement RB_POWEROFF
Jun 8 2020, 5:57 PM
jrtc27 closed D25183: riscv: Use SBI shutdown call to implement RB_POWEROFF.
Jun 8 2020, 5:57 PM

Jun 7 2020

jrtc27 requested review of D25183: riscv: Use SBI shutdown call to implement RB_POWEROFF.
Jun 7 2020, 11:58 PM

Jun 5 2020

jrtc27 added inline comments to D25151: RISC-V: handle DTB aligned to less than 2MB.
Jun 5 2020, 6:12 PM
jrtc27 updated the summary of D25153: RISC-V: Check that the DTB doesn't overlap with kernel.
Jun 5 2020, 5:32 PM
jrtc27 added a comment to D25152: sys/riscv: Remove debug printfs.

FWIW, this series of three printf's was copied directly from arm64's pmap_bootstrap.

Jun 5 2020, 5:25 PM

Jun 4 2020

jrtc27 requested review of D25132: virtio: Support non-legacy network device and queue.
Jun 4 2020, 7:02 PM

May 21 2020

jrtc27 added a comment to D24910: Add macros simplifying the fake preload setup.

That's a holdover from the a.out days. See D21099.

Neat, did you find that somehow or were you already aware of its usage? I'll remove that section in a follow-up.

May 21 2020, 6:53 PM
jrtc27 added inline comments to D24910: Add macros simplifying the fake preload setup.
May 21 2020, 6:19 PM
jrtc27 added a comment to D24910: Add macros simplifying the fake preload setup.

That's a holdover from the a.out days. See D21099.

May 21 2020, 6:00 PM

May 19 2020

jrtc27 added a comment to D24909: Simplify the RISC-V kernel linker invocation.

Yeah they don't need anything special, other than the ability to override KERNEL_LMA, which is kept here.

May 19 2020, 5:22 PM
jrtc27 added a comment to D24912: Handle load from loader(8).

https://lists.denx.de/pipermail/u-boot/2020-February/401563.html suggests Linux is going the way of an alternate entry point, FWIW.

May 19 2020, 1:59 AM
jrtc27 added a comment to D24912: Handle load from loader(8).

There is no guarantee that mhartid does not collide with the kernel's VA space. Unlikely, yes (especially since the spec encourages reducing the magnitude of the largest mhartid), but completely permitted. The only restriction on mhartid is this:

May 19 2020, 1:38 AM

May 13 2020

jrtc27 committed rS361010: riscv: Fix pmap_protect for superpages.
riscv: Fix pmap_protect for superpages
May 13 2020, 5:21 PM

May 7 2020

jrtc27 committed rS360789: virtio_mmio: Add casts missing from r360722.
virtio_mmio: Add casts missing from r360722
May 7 2020, 5:59 PM

May 6 2020

jrtc27 committed rS360723: virtio: Support MMIO bus for all devices.
virtio: Support MMIO bus for all devices
May 6 2020, 11:31 PM
jrtc27 closed D24730: virtio: Support MMIO bus for all devices.
May 6 2020, 11:31 PM
jrtc27 committed rS360722: virtio_mmio: Support non-transitional version 2 devices.
virtio_mmio: Support non-transitional version 2 devices
May 6 2020, 11:29 PM
jrtc27 closed D24681: virtio_mmio: Support non-transitional version 2 devices.
May 6 2020, 11:29 PM
jrtc27 added a comment to D24730: virtio: Support MMIO bus for all devices.
In D24730#544269, @br wrote:

we should also add these devices to riscv kernel config (at least random and console)

May 6 2020, 11:21 PM
jrtc27 added a comment to D24366: Align initial-exec TLS segments to the p_vaddr % align..

Do we not need an equivalent change to the frustratingly-duplicated parts in lib/libc/gen/tls.c for statically-linked binaries? Initial-exec is unusual but still valid there so long as your linker has statically filled in the relocations for the GOT, and can happen if you disable TLS linker relaxation (or use one of the architectures that can't relax TLS sequences).

May 6 2020, 6:36 PM
jrtc27 requested review of D24730: virtio: Support MMIO bus for all devices.
May 6 2020, 6:28 AM

May 4 2020

jrtc27 requested review of D24681: virtio_mmio: Support non-transitional version 2 devices.
May 4 2020, 1:06 AM

Apr 18 2020

jrtc27 added inline comments to D24487: Don't access a user buffer directly from the kernel..
Apr 18 2020, 8:00 PM

Apr 6 2020

jrtc27 committed rS359682: riscv: Add semicolon missing from r359672.
riscv: Add semicolon missing from r359672
Apr 6 2020, 11:55 PM
jrtc27 committed rS359672: riscv: Make sure local hart's icache is synced in pmap_sync_icache.
riscv: Make sure local hart's icache is synced in pmap_sync_icache
Apr 6 2020, 10:32 PM
jrtc27 closed D24317: riscv: Make sure local hart's icache is synced in pmap_sync_icache.
Apr 6 2020, 10:31 PM
jrtc27 closed D24315: riscv: Fix pmap_fault_fixup for L3 pages.
Apr 6 2020, 10:29 PM
jrtc27 committed rS359671: riscv: Fix pmap_fault_fixup for L3 pages.
riscv: Fix pmap_fault_fixup for L3 pages
Apr 6 2020, 10:29 PM
jrtc27 created D24317: riscv: Make sure local hart's icache is synced in pmap_sync_icache.
Apr 6 2020, 8:59 PM
jrtc27 updated jrtc27.
Apr 6 2020, 8:45 PM