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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.03.2026 16:06, Julian Vetter wrote:
> 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?

No. What I tried to convey is that besides Xen <-> DM negotiation, there
also needs to be Xen <-> DomU negotiation. While they shouldn't, existing
domains can write non-zero values, and the behavior of such domains
shouldn't change with your extension.

Jan