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....@citrix.com> > > --- > > 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.
