Re: [PATCH v4 8/9] hvm/ioreq: Negotiate extended destination ID support per ioreq server

[Jan Beulich <jbeulich@suse.com>]

On 28.04.2026 18:35, Teddy Astie wrote:
> Le 27/04/2026 à 15:57, Julian Vetter a écrit :
>> Add a per-server capability flag in XEN_DMOP_create_ioreq_server to
>> signal extended destination ID support. Repurpose the first byte of the
>> existing pad[3] as a flags field, and define
>> XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID (bit 0) for a server to signal it will
>> use XEN_DMOP_bind_pt_msi_irq for all passthrough MSI bindings.
>>
>> Track the flag in struct ioreq_server ext_dest_id.
>> hvm_ext_dest_id_enabled() returns true only if all registered ioreq
>> servers have opted in and at least one server is present. A single
>> server without the flag is sufficient to suppress the feature.
>>
>> Lock the feature at domain creation time:
>> arch_domain_creation_finished() computes the levelled result into struct
>> hvm_domain.ext_dest_id using OR to preserve any value previously
>> restored from an HVM save record. After creation_finished,
>> arch_ioreq_server_create_check() rejects new servers that lack
>> XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID if the feature was already advertised
>> to the guest.
>>
>> Persist the locked state in a new HVM_SAVE_TYPE(EXT_DEST_ID) record so
>> that migration preserves the guest-visible CPUID bit independently of
>> when the device model re-registers its ioreq servers on the destination
>> host.
>>
>> On restore, ioapic_check() uses d->arch.hvm.ext_dest_id (restored from
>> the EXT_DEST_ID record) rather than the per-server dynamic check, since
>> the DM has not yet re-registered its servers at that point.
>>
>> Update xendevicemodel_create_ioreq_server() in libxendevicemodel to
>> accept the new flags parameter, remove
>> xendevicemodel_enable_ext_dest_id(), and fix the
>> xc_hvm_create_ioreq_server() compat wrapper to pass zero flags.
>>
>> Signed-off-by: Julian Vetter <julian.vetter@vates.tech>
> 
> That has somewhat already being discussed previously, but AFAIU, 
> extended destination ID is only meaningful when guest APIC IDs cannot be 
> represented with the "non-extended" model which can only happen in 
> practice when having more than 128 vCPUs in the guest.

As Andrew has been pointing out many times, we need to stop thinking in
terms of 128 vCPU-s being the limit because of the vCPU ID times 2
calculation for the APIC IDs. With a non-HT topology, more than 128
vCPU-s would already be possible from an APIC ID perspective. Hence
tying "extended dest ID" to the vCPU count is unlikely to be viable.

Jan

> I don't think we need to check for device model support unless the guest 
> can have more than 128 vCPUs, where in such case it becomes mandatory 
> (unless some form of interrupt remapping is implemented).
> 
> So I would rather check if domain->max_vcpus is more than 128 and 
> require device models to implement support for extended destination ID 
> in these cases.
> 
> In some way, that would imply that extended destination ID is only 
> exposed to guests with domain->max_vcpus > 128.
> 
> Overall, what I propose would be to keep the new 
> XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID flag, and if d->max_vcpus > 128, we 
> require the device model to support XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID.