In D55429#1269504, @royger wrote:

I think I'm missing the previous changes that introduce the support for KVM, as those haven't landed in the git repository yet. FWIW, while the CPUID has been reserved on Xen, the implementation is not done, so there's no way to test it on Xen.

BTW we're going to need this ASAP if it's going to land in 14.4.

Only enable if ext_dest_id is set to -1.

Only enable if ext_dest_id is set to -1.

Only enable if ext_dest_id is set to -1.

Only enable if ext_dest_id is set to -1.

Switch machdep.msi_ext_dest_id to tristate

In D55430#1268961, @kib wrote:

Perhaps the defines should go into x86/include/specialreg.h together with all other CPUID bits definitions.

Made ext_dest_id static

Adjusted include guard to _X86_BHYVE_H_ instead of _BHYVE_H_

@royger Let me know if you'd like me to fix the signed-off-by line to avoid the mojibake, BTW. It looks like it was in the original Xen commit message and I didn't want to edit it without checking with you.

I "cherry-picked" this from the Xen repository, keeping the original author (Roger), date (2022), and commit message.

In D55292#1266346, @carlavilla wrote:

Tested on FreeBSD 15 with Hugo 0.155.3, works perfectly

One question, shall we add a link here[1] too?

[1] https://www.freebsd.org/releases/

FWIW I added that section in 14.0 because there were things which needed it, but I didn't add it to the template since I wasn't sure if it was going to be a regular thing -- but at this point I agree that adding it to the template is probably a good idea, there's likely to be more cloudy things happening and we can always remove it if the section ends up being empty. (Deleting empty sections of release notes is something I usually do just before the release.)

Don't CPU_ZERO for PPI/IPI with no handlers

In D55284#1265323, @andrew wrote:

Do we want to zero the CPU for PPIs & IPIs? I expect that check should be before the handlers == 0 check as they may be sent to all CPUs.

In D55284#1264897, @mhorne wrote:

I guess the alternative/redundant way to resolve this is for intr_setup_irq() to clear isrc->isrc_cpu when isrc->isrc_handlers == 0. This seems equally correct to me. Maybe an assertion added to that path would be revealing.

These are (obviously) generated by a shell script filing in a template; unfortunately since the shell script needs AWS credentials I can't share that. (Not that I want other people updating these files anyway!) If there are any changes needed I can feed them back into my templates though.

I agree with @ziaee, let's get this into the tree and keep working from there. During the release cycle I advertise the release notes as being a work in progress so there's no harm in having something which isn't fully polished yet.

I have tested in EC2 that this patch results in ena_handle_msix being called on 8 different CPUs (on this hardware we have 8 I/O queues) instead of only being called on CPU 0.