Ugh, I did not test it properly, and I think this version is totally broken...

In the future, please leave the revision open long enough for reviewers to have a chance to look at it. Even though the change is straightforward, and it was accepted by Mark, maybe I would have seen something that he didn't. For me, the change came and went completely before I got back from lunch. Thanks!

Rework the change; remove pmc_can_attach() entirely in favor of p_candebug().

Add few more tweaks. Remove the type changes.

There are further improvements to be made here, will update after some investigation.

Once I've landed the first few of these I will handle the remaining ops.

LGTM, thanks. I can push this to the main branch.

Link to the root of the src repo.

I forgot to submit this a while ago when I purged this info from hier(7).

Thanks! ...especially for the ordering fix :)

Thanks. I will commit this and D39820 today or tomorrow.

I am having difficulty trying to rationalize the acronym "FIQ" 🤔 😆

Looks good, one thing to fix.

In D40110#914389, @alfredo.mazzinghi_cl.cam.ac.uk wrote:

@mhorne I'm not sure how this currently is supposed to work, because the PMAP_MAPDEV_EARLY_SIZE constant is already larger than L2_SIZE in vmparam.h. So what we really want is also the DTB to be mapped at VM_EARLY_DTB_ADDRESS, which currently seems to be assumed to correspond to the second-to-last L2 entry in the devmap table. Is the PMAP_MAPDEV_EARLY_SIZE constant supposed to contain VM_EARLY_DTB_ADDRESS?

Absorbed by D39811.

Rebase.

Rebase. This patch becomes much simpler.

Rethink the series again; third time's the charm.

In order for this to work, you will need to fix the assembly in locore.S where we actually create the devmap mapping. There, we create it as a single 2MiB page beginning at (VM_MAX_KERNEL_ADDRESS - L2_SIZE).

Thanks for your work in handling this, @karels. The pw(8) changes, and tests, make sense to me, but it's not really my code to accept.

The wording used by the docs is confusing, but it is actually saying that disassemblers should output the aliases when possible.

I think the major version bump for 14.0 is a good thing, after going unchanged for a long while. I am certain that backwards compatibility has not been tested thoroughly in the last couple of years, and there are probably some subtle edge cases in which it has broken (for all I know I could be the culprit). This gives us a new baseline.

It is annoying, but this represents a new distinct error return from the syscall, and should be added to the ERRORS list in hwpmc(4).

The resulting cleanup is excellent.

Rebase and rename to printcpuinfo().

Rework the change a bit based on review comments.

This is simple, and makes sense to me. I think you should be consistent about which interpreter variant is the "yes" one; for efi and userboot it is "simp" but for i386 it is "4th".

In D40000#910859, @grahamperrin wrote:

Maybe refer to https://bugs.freebsd.org/261349 when committing. Thanks.