This is more of a RFC than a commit candidate. When I tried to use /dev/mem to access a register I got a "system error abort" panic (but mapping the same memory region with new-bus as a struct resource worked fine). The use case for me was using dd if=/dev/mem iseek=<register physical address/4> bs=4 count=1 | hd is how I got the SERR# panic. I'm not sure if the difference is that I should be using a different memattr perhaps? On amd64, this code uses pmap_kenter for the !can_fault case to avoid TLB shutdowns. I'm not sure that is as important for arm64 since shutdowns are presumably a bit cheaper which is why I did the lazy thing.

Ed noted that this file has grown very large, so this change trims it to only show entries for supported branches. In particular, if the goal (as I understand it) is to help porters know which versions to use when maintaining ports, then there isn't really a need to document values from unsupported branches.

Maybe to make it clearer we can change the struct to use a union of next_seqno and initial_seqno which won't change the ABI but will let us document it in the header and be more clear about the intent?

I actually have a much larger diff I'm working on to consistently use unsigned types for lengths in this header as well as fixing some potential integer overflow issues. I'll try to upload that later this week. I think I also fixed an overflow check in this patch as well as part of that.

Drop memset

Update after removing BUS_IVAR_GICV3

Rename BUS_IVAR_GIC3 to BUS_IVAR_GICV3

Hmm, so does (vm_offset_t)&end still work after this change or should it instead drop the &?

Ah, so you could use (char *)foo - end in place of the casts? But not &end?

I think we just need some sort of IVAR we can test for and this is just as easy as any other. Can you test this to make sure it works? I have only compile tested it as my only FreeBSD box with TB has the older chipsets that don't work.

In D54148#1237250, @igoro wrote:

In D54148#1237012, @jhb wrote:

Igor, are you able to test this again on your armv7 setup btw?

My testing passed. Now it's clear that my attempt to avoid extra copying on each reallocation was based on an assumption that isn't always true. It's a good plan to get back to always copying on each reallocation, as it was before, and think about an actual "buffer extension" mechanism that could be triggered when applicable.