On 20/12/2019 13:30, Jan Beulich wrote:
> The legacy vectors have been actively used on CPU 0 only. CPUs not
> sharing vector space with CPU 0 can easily re-use them, slightly
> increasing the relatively scarce resource of total vectors available in
> the system.
I suppose this technically depends on ExtINT messages never targeting
CPUs other than 0.
Either way - I think its fine restriction to rely on.
> As a result the legacy vector range simply becomes a
> sub-range of the dynamic one, with an extra check performed in
> _assign_irq_vector() (we can't rely on the
> "per_cpu(vector_irq, new_cpu)[vector] >= 0" check in the subsequent
> loop, as we need to also exclude vectors of disabled legacy IRQs).
>
> Suggested-by: Andrew Cooper <andrew.coop...@citrix.com>
> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>
> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -2389,8 +2389,7 @@ int ioapic_guest_write(unsigned long phy
> }
>
> if ( desc->arch.vector <= 0 || desc->arch.vector > LAST_DYNAMIC_VECTOR ||
> - (desc->arch.vector >= FIRST_LEGACY_VECTOR &&
> - desc->arch.vector <= LAST_LEGACY_VECTOR) )
> + desc->handler->enable == enable_8259A_irq )
> {
> int vector = desc->arch.vector;
>
> @@ -2617,7 +2616,7 @@ void __init init_ioapic_mappings(void)
>
> if ( nr_irqs == 0 )
> nr_irqs = cpu_has_apic ?
We should strip the !cpu_has_apic paths because they are obsolete in
64bit processors. I guess this can wait for a future cleanup series.
> - max(16U + num_present_cpus() * NR_DYNAMIC_VECTORS,
> + max(0U + num_present_cpus() * NR_DYNAMIC_VECTORS,
num_present_cpus() really can't be negative. Neither can
cpumask_weight(). With a bit of API cleanup, this 0U cast can be dropped.
However, given this is the only concerned, Acked-by: Andrew Cooper
<andrew.coop...@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
