Looks like this was independently submitted and fixed as 709c1049fe0c6d0217e81268d4f33f7191474453.

I committed this a few days ago, but it didn't get automatically closed before I didn't add a Differential Revision tag (because I wanted to keep the Xen commit unchanged).

ena(4) -> man:ena[4]

Remove comma per gperciva

I think it's just waiting for @salvadore to sign off on it.

Sync with reality

In D55857#1283609, @kib wrote:

In D55857#1283607, @cperciva wrote:

So... it's not an easy fix and definitely not an API change I can make quickly, and I don't want to hold up "better" just because we can't do "perfect" yet.

Sometimes even a promise would do.

In D55857#1283545, @kib wrote:

I still think that the error should somehow propagate up. With this series, the device is malfunctioning, with the only hint about the reason being the single cryptic line in the dmesg, which is not even attributed cleanly to the device.
It is better to fail the driver attach in this case than to offer such failure mode.

Print intpin when warning about unsupporting APIC IDs

@jhb @kib Do you anticipate being able to review this soon? I'd like to commit this stack of patches this week so it can bake in main for two weeks before MFCing in time for 15.1-RELEASE.

Personally I would put "move umount /dev into a new function" and "add comments" into different commits, but since you've already done it this way there's no point splitting them apart.

@jhb I think I've fixed this now, with a new io_valid field in D56006 being used to mark intpins as being invalid (and forcibly masked) due to having unsupported destinations.

Use io_valid

Use io_valid

In D55978#1280739, @ivy wrote:

the described behaviour seems like clearly a bug in pkg. from the pkgbase side, i don't mind this change as a workaround, but i wonder what the correct fix is here; do we want a separate package for 32-bit clang, like clang-lib32? clibs-lib32 is 3MB, which is relatively tiny compared to clang itself, but i think i'd prefer not to have any mandatory dependencies from native packages to compat packages - you should be able to completely ignore compat if you don't want it.

After more investigation: The culprit here is libclang_rt.asan-i386.so which is landing in FreeBSD-clang and creating the dependency on 32-bit libraries.

@ivy @bapt @ifreund_freebsdfoundation.org Tagging you here not so much to review the change but in case you have any idea what's going wrong in pkg.

@royger The handling of APIC RTEs is now in D55889. (The handling of MSIs remains in D55426, and there's now a new D55890 which creates the detect_extended_dest_id function which this revision adds Xen detection code to.)

@schakrabarti_microsoft.com I moved the detection code into local_apic.c since I'm using it for both MSIs and APIC RTEs now, but I assume since it's the same code your previous review applies equally well here.

Move detection code into local_apic.c

Move detection code into local_apic.c

Move detection code into local_apic.c

Move detection code into local_apic.c

Rework for apic_ext_dest_id shared with ioapic code

In D55857#1278564, @kib wrote:

Did you tried enabling DMAR/AMD IOMMU and interrupt remapping on this machine?

Add comment about keeping interrupt masked even when "enabling" it.

This is triggered by pointing an IRQ at lapic > 256, e.g. cpuset -l 193 -x 4 on an r8i.96xlarge system (note that on this system, CPUs 192--383 have APIC IDs 256--447).

In D55751#1276101, @leres wrote:

Note that https://bugs.freebsd.org/293654 has been solved by D55713. (I'm not clear on how to insure it is included in 15.1)

Thanks, [.filename] highlights the text in green and avoids the need to have a space between the path and the terminating period.

Use [.filename].

Thanks, I fixed the typo. Also I added periods at the end of sentences.

Update with new text