On Mon, Mar 09, 2026 at 12:31:03PM +0000, Julian Vetter wrote: > Xen cannot simply advertise XEN_HVM_CPUID_EXT_DEST_ID to the guest > without knowing that the device model will handle extended destination > IDs correctly for passthrough MSIs. A device model that still uses > XEN_DOMCTL_bind_pt_irq would pass only the low 8 bits of the destination > ID, misrouting interrupts to vCPUs with APIC IDs greater than 255. So, > add a DM op XEN_DMOP_enable_ext_dest_id that the device model can call > during domain setup (before vCPUs are started) to signal that it will > use XEN_DMOP_bind_pt_msi_irq for all passthrough MSI bindings. When > called, Xen sets ext_dest_id_enabled in struct hvm_domain, so it's > visible to the guest via CPUID.
Have you considered whether you could re-use the padding in XEN_DMOP_create_ioreq_server to signal whether the device model supports Extended ID parsing? Also, you might want some negotiation between multiple ioreq servers on the same domain. IOW: is multiple ioreq servers are registered ahead of the domain having finished creation you could level whether extended ID should be announced. For ioreqs that are registered after the domain have started you need to enforce the currently set Extended ID support. If the domain is running, and Extended ID is advertised you must prevent registering any new ioreq that doesn't support Extended ID. Thanks, Roger.
