Re: [PATCH] x86/hvm: Advertise and support extended destination IDs for MSI/IO-APIC

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.02.2026 14:52, Julian Vetter wrote:
> 
> 
> On 2/19/26 14:28, Jan Beulich wrote:
>> On 19.02.2026 14:08, Julian Vetter wrote:
>>> On 2/9/26 14:40, Teddy Astie wrote:
>>>> Le 09/02/2026 à 12:36, Julian Vetter a écrit :
>>>>> --- a/xen/arch/x86/hvm/vioapic.c
>>>>> +++ b/xen/arch/x86/hvm/vioapic.c
>>>>> @@ -411,7 +411,7 @@ static void ioapic_inj_irq(
>>>>>     
>>>>>     static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int 
>>>>> pin)
>>>>>     {
>>>>> -    uint16_t dest = vioapic->redirtbl[pin].fields.dest_id;
>>>>> +    uint32_t dest = VIOAPIC_RTE_DEST(vioapic->redirtbl[pin].bits);
>>>>
>>>> I would rather introduce a new field in vioapic_redir_entry for the
>>>> extended dest part; and compute dest from that and dest_id.
>>>
>>> Here I have a question. This struct is a public ABI struct.
>>> vioapic_redir_entry is defined in
>>> xen/include/public/arch-x86/hvm/save.h. It's part of XENs VM
>>> save/restore operation. It is used by libxc and toolstacks to migrate
>>> VMs between hosts. Changing the struct might be undesirable? Yes, it
>>> would make the code cleaner. having a bit entry for the extended dest
>>> bits. What's the general opinion on this? With the VIOAPIC_RTE_DEST
>>> macro I avoided touching this struct...
>>
>> Which in turn raises the question: How do you migrate those bits? It looks
>> like you're losing them.
> 
> The bits are preserved correctly. The migration saves/restores the full 
> uint64_t bit union member, not the individual bit fields.

Which is, aiui, only because for the IO-APIC we haven't introduced "check"
hooks, yet. Which, yes, ...

> But, the issue 
> is maybe in the other direction? If we migrate a VM from a new XEN 
> (where the guest has programmed extended dest IDs into RTEs) to an old 
> XEN that doesn't understand them. The raw bits would be restored 
> correctly into bits, but the old XENs vioapic_deliver only reads 
> fields.dest_id (8 bits) and would silently ignore the extended bits. The 
> guest would end up with broken interrupt routing to vCPUs with APIC ID > 
> 255.

... goes along of what you're saying here.

> But there is not much we can do?!

The bits need explicitly migrating (which may well be as part of the RTE,
as you describe), with checking as mentioned above in place. That checking
would refuse the migration prior to your patch (or when the feature is
disabled for the guest), and allow it through afterwards (when the feature
is enabled for the guest).

Jan