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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Feb 16, 2022 at 10:53:58AM +0000, Durrant, Paul wrote:
> 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.

Right - so device models wanting to support > 128 vCPUs will already
need to be modified, and hence we could assume that any HVM guests
with > 128 vCPUs is using a device model capable of handling extended
destination ID?

Thanks, Roger.