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. 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. But there is not much we can do?!
>
> Jan
--
Julian Vetter | Vates Hypervisor & Kernel Developer
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
