Re: [PATCH v4 9/9] x86/cpuid: Advertise XEN_HVM_CPUID_EXT_DEST_ID when device model opts in

[Jan Beulich <jbeulich@suse.com>]

On 27.04.2026 15:54, Julian Vetter wrote:
> Set the XEN_HVM_CPUID_EXT_DEST_ID bit in the HVM hypervisor CPUID leaf
> based on the domain-level ext_dest_id flag, which is locked at domain
> creation time by taking the AND across all registered ioreq servers that
> set XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID. This guarantees that the bit is
> only advertised when every active device model will use
> XEN_DMOP_bind_pt_msi_irq for passthrough MSIs, so Xen can decode the
> extended destination bits from the raw MSI address internally.
> 
> After creation_finished the locked d->arch.hvm.ext_dest_id is used
> directly, providing a stable and migration-safe value independent of
> whether ioreq servers have been re-registered yet. Before
> creation_finished the dynamic per-server check is used so toolstack
> queries during domain setup reflect the current state.

What toolstack queries to you have in mind here? Did you check ...

> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -1,3 +1,4 @@
> +#include <xen/ioreq.h>
>  #include <xen/sched.h>
>  #include <xen/types.h>
>  #include <xen/version.h>
> @@ -148,6 +149,18 @@ static void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf,

... call sites of this function? It's solely guest_cpuid(), and all
callers of the latter act on current. I.e. if there was a need for a
toolstack to find out (transient) state, it would need to be through
a different interface anyway.

Jan