Re: [PATCH v2] x86/x2apic: introduce a mixed physical/cluster mode

[Jan Beulich <jbeulich@xxxxxxxx>]

On 31.10.2023 15:52, Roger Pau Monne wrote:
> --- a/xen/arch/x86/genapic/x2apic.c
> +++ b/xen/arch/x86/genapic/x2apic.c
> @@ -180,6 +180,29 @@ static const struct genapic __initconstrel 
> apic_x2apic_cluster = {
>      .send_IPI_self = send_IPI_self_x2apic
>  };
>  
> +/*
> + * Mixed x2APIC mode: use physical for external (device) interrupts, and
> + * cluster for inter processor interrupts.  Such mode has the benefits of not
> + * sharing the vector space with all CPUs on the cluster, while still 
> allowing
> + * IPIs to be more efficiently delivered by not having to perform an ICR 
> write
> + * for each target CPU.
> + */
> +static const struct genapic __initconstrel apic_x2apic_mixed = {
> +    APIC_INIT("x2apic_mixed", NULL),
> +    /*
> +     * NB: IPIs use the send_IPI_{mask,self} hooks only, other fields are
> +     * exclusively used by external interrupts and hence are set to use
> +     * Physical destination mode handlers.
> +     */
> +    .int_delivery_mode = dest_Fixed,
> +    .int_dest_mode = 0 /* physical delivery */,
> +    .init_apic_ldr = init_apic_ldr_x2apic_cluster,

INT_DEST_MODE and the init_apic_ldr hook pointer are used in one place
that's neither IPI nor device-IRQ related: What connect_bsp_APIC() logs
is already not really correct for x2APIC mode, but clearly things go
worse with this further extension of the possible modes. I think this
wants adjusting to cover the (now) three x2APIC modes as well. (It
could also be updated up front to deal with the two original x2APIC
modes, but personally I'd fold the whole change right into here.)

Jan