On Tue, Oct 13 2020 at 12:51, David Woodhouse wrote:
> With that realisation, I've fixed the comment in my ext_dest_id branch
> to remove all mention of IRQ remapping. It now looks like this:
>
> static int x86_vector_select(struct irq_domain *d, struct irq_fwspec *fwspec,
> enum irq_domain_bus_token bus_token)
> {
> /*
> * HPET and I/OAPIC drivers use irq_find_matching_irqdomain()
> * to find their parent irqdomain. For x86_vector_domain to be
> * suitable, all CPUs in the system must be reachable by its
> * x86_vector_msi_compose_msg() function. Which is only true
> * in !x2apic mode, or in x2apic physical mode if APIC IDs were
> * restricted to 8 or 15 bits at boot time. In those cases,
> * 1<<15 will *not* be a valid APIC ID.
> */
> if (apic->apic_id_valid(1<<15))
> return 0;
>
> return x86_fwspec_is_ioapic(fwspec) || x86_fwspec_is_hpet(fwspec);
> }
>
> That makes it clearer that this isn't just some incestuous interaction
> with IRQ remapping — that APIC ID limit really is the basis on which
> this irqdomain, all by itself, makes the decision about whether it's
> capable of being the parent irqdomain to the requesting device.
Yes, that makes sense now.
Thanks,
tglx
