Re: [PATCH v3 3/7] x86/hvm: Support extended destination IDs in virtual MSI and IO-APIC

["Julian Vetter" <julian.vetter@xxxxxxxxxx>]

On 3/12/26 12:15 PM, Jan Beulich wrote:
> On 11.03.2026 16:27, Jan Beulich wrote:
>> On 09.03.2026 13:31, Julian Vetter wrote:
>>> @@ -618,6 +620,21 @@ static int cf_check ioapic_check(const struct domain 
>>> *d, hvm_domain_context_t *h
>>>                e->fields.reserved[0] || e->fields.reserved[1] ||
>>>                e->fields.reserved[2] || e->fields.reserved2 )
>>>               return -EINVAL;
>>> +
>>> +        /*
>>> +         * An RTE in the saved state has ext_dest_id bits set. Check that
>>> +         * the destination Xen has extended destination ID support enabled,
>>> +         * otherwise interrupt routing to APIC IDs > 255 would be broken
>>> +         * after restore.
>>> +         */
>>> +        if ( e->fields.ext_dest_id && !d->arch.hvm.ext_dest_id_enabled )

Thank you for your feedback Jan! Yes, right the 'ext_dest_id_enabled' 
must be defined before it can be checked. I have rearranged this in my 
patch set.

>>
>> This won't build, as the ext_dest_id_enabled field appears only in patch 6.
>> But yes, that looks to be the opt-in mechanism I mentioned above.
> 
> Actually no, how could it be. That's for the DM to invoke.

But this comment here I'm not sure I fully understand. You mean that 
checking 'if ( e->fields.ext_dest_id && !d->arch.hvm.ext_dest_id_enabled 
)' is not enough? This check only verifies that if the target domain 
doesn't support ext_dest_id_enabled, no RTE in the source domain is 
allowed to have a ext_dest_id set. But now we also have to check that if 
the source domain has ext_dest_id_enabled, the target also have to 
announce it, right? So,

if ( s->ext_dest_id_enabled && !d->arch.hvm.ext_dest_id_enabled )
{
     //ERROR
}

Is this what you meant?

Julian

> 
> Jan



--
Julian Vetter | Vates Hypervisor & Kernel Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech