Shouldn't this be an error? When we fail with registering device, we end up with non-working MSI/MSIx for the whole system and the driver successfully loaded.

You seem to be requesting a contiguous range of interrupts and mapping them 1:1. This is the sort of thing intr_pic_add_handler was designed to handle. You might need to tell the GICv3 driver to send this range to the child.

Why not use vmem(9) to manage this? I've done so in the GICv3 ITS driver if you would like a reference.

Can you not use ofw_bus_map_intr?

I know, but currently the child handler is called only in the case of LPIs so it only works with ITS on ARM64. I did not want to introduce delay in arm_gic_v3_intr() by adding additional branches, but perhaps it should somehow be resolved so that not only ITS is supported as child. Another potential issue is that the 'msix' node here is not really a child of GICv3 node in DTS - it is at the same level under 'soc'.

That only decodes the IRQ number, while PIC_MAP_INTR provides the isrc from GIC which we can return to the caller.

Diff 21508 switches management to vmem. Had some trouble with it because vmem_alloc() seems to eventually fail when smallest unit of allocation is set to 1 and qcache_max is also 1. In ITS you always allocated more than one element at a time and I suppose that's why it worked for you - I think you should look into what happens when you try to allocate only one item. In my case a few initial allocations were successful but then it returned ENOMEM even though there was still a lot of free elements.