Re: [PATCH v2 2/2] vsmp: Ignore IOAPIC IRQ affinity if possible

[Ingo Molnar]

* Ido Yariv <ido@xxxxxxxxxx> wrote:

> From: Ravikiran Thirumalai <kiran.thirumalai@xxxxxxxxx>
> 
> vSMP can route interrupts more optimally based on internal knowledge the
> OS does not have. In order to support this optimization, all CPUs must
> be able to handle all possible IOAPIC interrupts.
> 
> Fix this by setting the vector allocation domain for all CPUs and by
> enabling this feature in vSMP.
> 
> Signed-off-by: Ravikiran Thirumalai <kiran.thirumalai@xxxxxxxxx>
> Signed-off-by: Shai Fultheim <shai@xxxxxxxxxxx>
> [ido@xxxxxxxxxx: rebased, simplified, and reworded the commit message]
> Signed-off-by: Ido Yariv <ido@xxxxxxxxxx>
> ---
> Changes from v1:
> - Updated Kiran's email address
> 
>  arch/x86/kernel/apic/probe_64.c |   10 ++++++++++
>  arch/x86/kernel/vsmp_64.c       |   15 +++++++++++----
>  2 files changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kernel/apic/probe_64.c b/arch/x86/kernel/apic/probe_64.c
> index 3fe9866..0f96703 100644
> --- a/arch/x86/kernel/apic/probe_64.c
> +++ b/arch/x86/kernel/apic/probe_64.c
> @@ -29,6 +29,15 @@ static int apicid_phys_pkg_id(int initial_apic_id, int index_msb)
>  }
>  
>  /*
> + * In vSMP, all cpus should be capable of handling interrupts, regardless of
> + * the apic used.
> + */
> +static void fill_vector_allocation_domain(int cpu, struct cpumask *retmask)
> +{
> +	cpumask_setall(retmask);
> +}
> +
> +/*
>   * Check the APIC IDs in bios_cpu_apicid and choose the APIC mode.
>   */
>  void __init default_setup_apic_routing(void)
> @@ -51,6 +60,7 @@ void __init default_setup_apic_routing(void)
>  	if (is_vsmp_box()) {
>  		/* need to update phys_pkg_id */
>  		apic->phys_pkg_id = apicid_phys_pkg_id;
> +		apic->vector_allocation_domain = fill_vector_allocation_domain;
>  	}
>  }

This is_vsmp_box() special case should really move into its own 
apic handler.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/