Re: [PATCH v2 RFC 4/5] x86/ioreq: report extended destination ID support by emulators

["Durrant, Paul" <xadimgnik@xxxxxxxxx>]

On 16/02/2022 10:30, Roger Pau Monne wrote:
> Introduce a new arch specific field to report whether an emulator
> supports the Extended Destination ID field, so that the hypervisor can
> refrain from exposing the feature if one of the emulators doesn't
> support it.
>
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> ---
> Changes since v1:
>   - New in this version.
> ---
> RFC: I find this kind of clumsy. In fact fully emulated devices
> should already support Extended Destination ID without any
> modifications, because XEN_DMOP_inject_msi gets passed the address and
> data fields, so the hypervisor extracts the extended destination ID
> from there.
>
> PCI passthrough devices however use xc_domain_update_msi_irq and that
> has leaked the gflags parameter in the API, even worse the position
> of the flags are hardcoded in QEMU.
>
> Should the clearing of ext_dest_id be limited to the domain using an
> IOMMU?
>
> RFC: Only enable ext_dest_id if max_cpu > 128? So the device model is
> aware the domain must use ext_dest_id? (implies device model knows
> APIC ID = CPU ID * 2)
There is still only a single sync ioreq server page, so 128 vCPUs is the 
max possible.
  Paul