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

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

On 16/02/2022 11:32, Roger Pau Monné wrote:
> 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?
Yes, exactly.

  Paul