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.
Jan
