Exp-run requested here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244383

Of course, I'd rather we just kill SCTL_MASK32 entirely and use SV_PROC_FLAG checks to replace it, but that's a separate (and larger) change we've already discussed in person.

Hmm, actually, my branch removed more of it I think which I'd rather do if we want to kill it:

So in CheriBSD we just replaced all of atomic(9) with the __atomic API supported in both modern GCC and clang for RISC-V:

• Remove OBE workaround from ccr_eta_done.
• Don't permit DECRYPT | COMPUTE for ETA.
• accellerate -> accelerate.
• Let OCF verify HMACs for ETA.
• Update crp_mbuf instead of leaking q_dst_m.

Generally looks fine. Only weirdness is having to mark SYSCTL_NODE()'s with MPSAFE. A SYSCTL_NODE without an explicit handler (so handler set to NULL) is inherently MPSAFE, and it'd be nice to adjust the assertions to special case that to avoid adding churn since eventually once al sysctls are safe we will go through and remove all the CTLFLAG_MPSAFE flags.

I vote for using the parenthetical.

I'm not really sure why we need more interrupt types? This seems like it is better named INTR_TYPE_NET_NOEPOCH or something anyway, and if that's the true purpose I think instead we might need to rethink the design of tying the network epoch to the interrupt type? For example, what if instead of teaching ithreads, task queues, etc. about the network epoch directly, we were to have drivers that want to coalesce the epoch do so explicitly in their ISR (this also would let them drop the epoch when doing voluntarily yielding which is one thing np@ asked about on IRC earlier) and either use an alternate if_input or a new if_flags to avoid the recursion in ether_input? I think that approach would be fairly simple while avoiding hardcoding knowledge about the network epoch in various kernel subsystems.

Yes, this is what lets you use base/gcc. WITH_PORTS_BASE_BINUTILS is also still relevant. These knobs are enabled by the base/* packages so that 'make delete-old' doesn't delete files installed by the packages as the commit message that added them explains.

In D10335#516265, @jceel wrote:

In D10335#516241, @jhb wrote:

So this looks good to me, but the latest upload lost all the lib9p sources. I finally found the lib9p upstream, though the only version I see is in your GitHub space? I would be fine with still using that as an upstream though and putting the sources into contrib/lib9p (despite the last call where I said it could move). I think it would be good to first import lib9p into the vendor/ space and then contrib/, then a commit to hook it up to the build (being able to hook the tests up to run as part of the kyua test suite runs would be a bonus), and finally the commit to add it to bhyve 3rd.

Can you elaborate on what I did wrong with the latest patch update? I generated it using arc diff HEAD^^ -- update D10335 which resulted in a diff only in files changed since last upload (two git commits from my development branch on github).

I would still rather keep sys/dev/pci for "generic" PCI things such as the PCI-PCI bridge driver or the PCI bus driver, etc. sys/arm64/pci could also be a place (for x86 we use sys/{amd64,i386,x86}/pci to hold MD PCI drivers that don't belong elsewhere)

Are there other drivers for this chipset? If so, sys/arm64/n1sdp might be a good place for neoverse 1-specific drivers to live. sys/dev/n1sdp could also work (though on arm platforms we've tended to put them in sys/arm/<chipset|soc> rather than sys/dev)

Yes, it was probably copied from arm64 originally. Fixing it on those platforms requires auditing makectx() to make sure it DTRT however.

So this looks good to me, but the latest upload lost all the lib9p sources. I finally found the lib9p upstream, though the only version I see is in your GitHub space? I would be fine with still using that as an upstream though and putting the sources into contrib/lib9p (despite the last call where I said it could move). I think it would be good to first import lib9p into the vendor/ space and then contrib/, then a commit to hook it up to the build (being able to hook the tests up to run as part of the kyua test suite runs would be a bonus), and finally the commit to add it to bhyve 3rd.

Hmm, I don't understand the original logic either. Note that at the time we didn't have KLD_TIED, so it would have applied to kernel modules built together with the kernel. Given the author, it must have been dtrace related? I think your change is fine.

As with the xilinx driver, can we please not put MD and chipset-specific code in sys/dev/pci?

Existing format for debug.kdb.trap=1:

Probably should add the new function to the lvm(3) manpage.

• Fixup to use SSTATUS_SD.

I think removing in 13.0 might be a bit aggressive. I've certainly run into several developers who still use this instead of etcupdate. We also haven't updated any of our docs in the handbook to mention etcupdate (wblock@ tried but gave up when he ran into issues I didn't understand when trying to use etcupdate). I do think a runtime warning might also be warranted, though likely to be lost in the noise that mergemaster generates. Making sure the handbook documents etcupdate is probably a prerequisite for deprecating it.

So one question I have is if 'make xdev' makes sense in a clang world? clang is already a cross-compiler via -target. Probably not for this change, but if 'make xdev' is now obsolete it might be nice to GC those bits as a followup.

It used to be .So but was changed to .pico in https://svnweb.freebsd.org/base?view=revision&revision=306297. In this particular case there isn't a .so that it would collide with, so it could go back to .So perhaps, but I'm not going to bother with that anytime soon.

This actually boots. The first version would boot in qemu, but /usr/bin/login would fail. I added printfs to the EINVAL case and found that the values of SD and FS were varying triggering the false failures. On further thinking, restoring the original FS would not be correct anyway. It should either be OFF or CLEAN as I said earlier. I didn't read the description of MSTATUS exhaustively, but I don't think there are any other read-only bits in SSTATUS?

• Ignore read-only bits and FS in sstatus.

(I found out the SD and FS stuff while testing it in QEMU btw and am testing the changes I mentioned)

This is actually broken. It flags what look like changes in SD and FS that are bogus (and we should also ignore XS since it is read-only). For FS, the real fix is that set_fpcontext() needs to be setting that field explicitly based on what it does. It either needs to turn FP off if there was no valid state to save, or it needs to set it to clean since it just restored the registers and they are now all match the saved state. I don't think we want to let userland change UXL though? If we supported riscv32 and freebsd32, then you would set UXL during the freebsd32 exec_setregs(), but it would otherwise need to be static until the next exec?

Putting this in sys/dev/xilinx probably makes more sense than putting this in sys/dev/pci which is generally only for cross-platform PCI standard things. You could then name it xlnx_pcib.[ch] (or xilinx_pcib.[ch]).