Re: [PATCH 5/5] x86/kvm: Add KVM_FEATURE_MSI_EXT_DEST_ID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux