I'm afk for a week and a half

While here I think it would make sense to also handle this case in tag_check_abort, although I don't think we can currently hit it there (no tag checking in the kernel).

In D58212#1335516, @mmel wrote:

In D58212#1335515, @bz wrote:

I think the only thing I'd love to see is to tell users in the commit message how to apply this as it seems this needs to be done manually.

The fixup is applied automatically if your CPUTYPE is set to 'generic', 'armv8-a', 'cortex-a53' or if it is left empty.

How does this compare with D55474?

For the IOMMU we use a separate busdma implementation. It looks like the dma-ranges property on an iommu is to translate between the translated iommu address and a cpu physical address. Because of this I don't think it's a problem there as devices behind an iommu will use a virtual address, so can allocate addresses as needed.

How will this work with the tags boundary, lowaddr and highaddr? We allocate memory assuming these are CPU physical addresses, but they should be bus addresses.

• Stop cleaning tags in pmap_enter after D57990
• Set the VM_MEMATTR_TAGGED attribute in more pmap functions
• Make PROT_MTE visible on all architectures
• Add VM_PROT_MTE
• Disallow chaning PROT_MTE in mprotect
• Also check if max_prot has PROT_MTE for non-anon mapping in mmap

• Fix an inline asm constraint
• Use mte_enabled to decide to allocate the MTE swap zone
• Call swblk_lookup with the object lock
• Rebase to use PV_MTE_CLEAN & atomically check the flag

Only allow PROT_MTE with MAP_ANON

Rebase & use a pointer in mte_{load,save}_tags

In D55957#1314750, @brooks wrote:

In CheriBSD we have a somewhat different mechanism where we embed the tags in struct swblk due to a hesitance to add more allocation to the swap path. That's not great for memory usage since it's quite a lot of space and it should be fairly compressible in most cases. I'd expect MTE to be before more compressible given it's often going to be runs of the same value. I think we could adapt this code to add CHERI tags, likely in parallel, though maybe with a shared scan loop.

I looks like some lines might be wider than 80 characters

Is this something cheri could use too?

It looks like a few lines passed 80 characters so will need to be split.

We should name __hypctx_vncr_sysreg to __hypctx_vncr_sysreg_64 or similar to indicate it supports 64-bit registers (and the other accessors). CHERI could add a version to indicate it handles capabiliries (or it handles pointer-like registers).

Use D57017 to build the instructions

• Remove the unneeded bind handler
• Cleanup better on attach failure

• Clean up table size/alignment handling
• Read the table PA range from the register
• Support 2 level device tables
• Support a non-coherent ITS
• Cleanup better on attach failure
• Implement more functions

• Clean up table size/alignment handling
• Read the table PA range from the register
• Handle IPIs without having to change common code