Re: [PATCH v4 8/9] hvm/ioreq: Negotiate extended destination ID support per ioreq server

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.08.2026 10:52, Julian Vetter wrote:
> On 8/19/26 16:38, Jan Beulich wrote:
>> On 27.04.2026 15:54, Julian Vetter wrote:
>>> @@ -1106,7 +1107,16 @@ int arch_domain_soft_reset(struct domain *d)
>>>   void arch_domain_creation_finished(struct domain *d)
>>>   {
>>>       if ( is_hvm_domain(d) )
>>> +    {
>>> +        /*
>>> +         * Lock the extended destination ID state. OR preserves any value
>>> +         * already restored from an HVM save record (migration path). For a
>>> +         * fresh domain, ext_dest_id starts false and the dynamic check
>>> +         * supplies the levelled result across all registered ioreq 
>>> servers.
>>> +         */
>>> +        d->arch.hvm.ext_dest_id |= hvm_ext_dest_id_enabled(d);
>>
>> For an unaware guest, after migration it'll suddenly get the flag set
>> if all servers are capable. That can't be right. It looks pretty much
>> unavoidable for the field to become tristate (unset / false / true).
> 
> Thank you Jan. You're right true/false is not enough, but there's one 
> migration case left where even a tristate doesn't give a clear answer, I 
> believe and I'd like your opinion on that.
> 
> Scenario: a domain is migrated (or saved/restored) from a Xen that 
> predates this series, onto a new Xen where every registered ioreq server 
> has XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID set.
> 
> So, the incoming stream would not carry a EXT_DEST_ID record, so 
> ext_dest_id_load() never runs and the field would still be 
> EXT_DEST_ID_UNSET when arch_domain_creation_finished() runs on the 
> destination. The latch then takes the "fresh domain" path and recomputes 
> the levelled value, which here comes out ENABLED.

Well - I thought it was clear that by the time the domain is actually
launched, the 3rd ("unset") value would need resolving.

>  From that point Xen would interpret the extended destination ID bits 
> for this guest. But before the guest ran under a Xen that never 
> advertised XEN_HVM_CPUID_EXT_DEST_ID, so it never used those reserved 
> bits deliberately, but might have written garbage into them accidentaly.
> 
> I see two ways to handle this:
> 
> 1. Accept it. Document that migrating in from a pre-feature Xen onto an 
> all-opted-in host may turn the feature on, and might now treat non-zero 
> reserved bits as extended destionation ID bits.
> 2. Distinguish "fresh domain" from "restored without the record" and 
> force the latter to DISABLED. A feature-aware guest then picks the 
> feature up on its next reboot on the new host, which matches how every 
> other creation-time-levelled property behaves.

Imo 2 is the only viable option.

> The stream is parsed by Xen (the toolstack hands the HVM-context blob to 
> XEN_DOMCTL_sethvmcontext -> hvm_load()), so this stays entirely in the 
> hypervisor: add a 'bool context_loaded' to 'struct hvm_domain', set it 
> in the hvm_load(), and in the latch do
> 
> if ( d->arch.hvm.ext_dest_id == EXT_DEST_ID_UNSET )
>       d->arch.hvm.ext_dest_id =
>          (!d->arch.hvm.context_loaded && hvm_ext_dest_id_enabled(d))
>          ? EXT_DEST_ID_ENABLED : EXT_DEST_ID_DISABLED;
> 
> This would mean one new bool in 'struct hvm_domain' which covers both 
> live migration and xl restore of an old image. What do you think? Would 
> this be acceptable?

I don't quite get why that's better than converting the boolean to a
tristate.

Also may I please remind you again to trim your replies? Below here,
for example, there was only reply quoting. That serves no purpose in
your reply. Yet I still needed to scroll through all of it to see
whether there was some other comment of yours. And every other reader
likely will also end up doing so.

Jan