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

Re: [PATCH v2] x86/i8259: do not assume interrupts always target CPU0


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 24 Oct 2023 13:36:13 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4j9mYNdEBLobWKQtvM3lP0y2DWfbGLHDV4nSpwh1qEg=; b=JwQAEnDMNYsA3lEe1IQaw0OSB8FKwdY2ljfRhm9gy9zrHkTg43EvHHYqwc4x5UkkSO9sI2PFINIyRd+cnFgnnspLIkGNOlXsCIqL0LSo2dEIzA/meGaZwmYVosuU9BAyF81Q4DK1lS2U1UQstC4EGGMfVih5Lt6h6lOG//+Q4H9PTJ0MVDQsoYxA/V4dbQ7PzwL2lpUDS/msPrcVB9Dq6VahMQGbNA6EOU/X9+IXEjYvbvrwxtzC7NTKUqfrJhbX89W0IDC0UK8lmcclryQUozLoLkCbvF5fJ/sOgg25Tcf5ZqWWDR0TOBPWSZNCFcCSUjZz1TRShWDR4McS/3ABrA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gdhQRBT1nOmQ2eEdaPcLkcixGqqXzOtZbWjv2/RuEJLjFmE8NrVBKmB88IQ7DqQugmRKz9QYvSnjBVxDkDUAPba7DdRwIHCveLWQUV8jqaefh2Q1+PnfYlR3MMeeV3BEb13zE8NmyKJWd2Kn3CGYKFz2eMR2tK58KlRUXa3B0EQ5GUTxClpNTjePGPF3x75Vk45LCESlSvRJwDeEmAx557aoLyxkFII6wRg1Fuxz1wg5VnUyKAN+KU9/jZyDflWGfyE4ARjRzPdgJP5RgXuVYvGH282Q/aKDvSmncm3x5Mx254CIHiCc3GCWiYvF+ahMpdsxj7LIpgGG/1/xlWd7ww==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 24 Oct 2023 11:36:39 +0000
  • Ironport-data: A9a23:LQWWQaKuNiNNu3ISFE+R9pQlxSXFcZb7ZxGr2PjKsXjdYENS0mFSz zEaCGnVM/uMMWr3LYxwa4219RtQuMDSzNE2GQZlqX01Q3x08seUXt7xwmUcnc+xBpaaEB84t ZV2hv3odp1coqr0/0/1WlTZhSAhk/nOHvylULKs1hlZHWdMUD0mhQ9oh9k3i4tphcnRKw6Ws Jb5rta31GWNglaYCUpKrfrYwP9TlK6q4mhB5gZiPakjUGL2zBH5MrpOfcldEFOgKmVkNrbSb /rOyri/4lTY838FYj9yuu+mGqGiaue60Tmm0hK6aYD76vRxjnVaPpIAHOgdcS9qZwChxLid/ jnvWauYEm/FNoWU8AgUvoIx/ytWZcWq85efSZSzXFD6I+QrvBIAzt03ZHzaM7H09c5cDm1ep acbIwldZzubveXm3a60aclj05FLwMnDZOvzu1lG5BSBV7MKZMuGRK/Ho9hFwD03m8ZCW+7EY NYUYiZuaxKGZABTPlAQC9Q1m+LAanvXKmUE7g7K4/dppTSKpOBy+OGF3N79YNuFSN8Thk+Fj mnH4374ElcRM9n3JT+tqyjy3bOUzHKgMG4UPJuF2acwknOM/3EaI14ndgefv9q6rnfrDrqzL GRRoELCt5Ma9kamU938VB2Qu2Ofs1gXXN84O/I+wBGAzOzT+QnxLngJSHtNZcIrsOcyRCc2z RmZktXxHzttvbaJD3WH+d+pQSiaPCEUKSoOYHQCRA5dud37+tlv11TIU8ppF7OzgpvtAzbsz juWrS84wbIOkcoM0Kb99lfC696xmqX0oscOzl2/dgqYAslRPuZJu6TABYDn0Mt9
  • Ironport-hdrordr: A9a23:vGHPjq9dJjHrMfxnYu5uk+AuI+orL9Y04lQ7vn2ZKSY5TiVXra CTdZUgpHnJYVMqMk3I9uruBEDtex3hHNtOkOss1NSZLW7bUQmTXeJfBOLZqlWNJ8S9zJ856U 4JScND4bbLfDxHZKjBgTVRE7wbsaa6GKLDv5ah85+6JzsaGp2J7G1Ce3am+lUdfng+OXKgfq Dsm/auoVCbCAwqR/X+PFYpdc7ZqebGkZr3CCR2eyLOuGG1/EiVAKeRKWnj4isj
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, Oct 24, 2023 at 12:51:08PM +0200, Jan Beulich wrote:
> On 24.10.2023 12:14, Roger Pau Monné wrote:
> > On Tue, Oct 24, 2023 at 11:33:21AM +0200, Jan Beulich wrote:
> >> On 23.10.2023 14:46, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/i8259.c
> >>> +++ b/xen/arch/x86/i8259.c
> >>> @@ -37,6 +37,15 @@ static bool _mask_and_ack_8259A_irq(unsigned int irq);
> >>>  
> >>>  bool bogus_8259A_irq(unsigned int irq)
> >>>  {
> >>> +    if ( smp_processor_id() &&
> >>> +         !(boot_cpu_data.x86_vendor & (X86_VENDOR_AMD | 
> >>> X86_VENDOR_HYGON)) )
> >>> +        /*
> >>> +         * For AMD/Hygon do spurious PIC interrupt detection on all 
> >>> CPUs, as it
> >>> +         * has been observed that during unknown circumstances spurious 
> >>> PIC
> >>> +         * interrupts have been delivered to CPUs different than the BSP.
> >>> +         */
> >>> +        return false;
> >>> +
> >>>      return !_mask_and_ack_8259A_irq(irq);
> >>>  }
> >>
> >> I don't think this function should be changed; imo the adjustment belongs
> >> at the call site.
> > 
> > It makes the call site much more complex to follow, in fact I was
> > considering pulling the PIC vector range checks into
> > bogus_8259A_irq().  Would that convince you into placing the check here
> > rather than in the caller context?
> 
> Passing a vector and moving the range check into the function is something
> that may make sense. But I'm afraid the same does not apply to the
> smp_processor_id() check, unless the function was also renamed to
> bogus_8259A_vector(). Which in turn doesn't make much sense, to me at
> least, as the logic would better be in terms of IRQs (which is what the
> chip deals with primarily), not vectors (which the chip deals with solely
> during the INTA cycle with the CPU).

The alternative is to use:

            if ( !(vector >= FIRST_LEGACY_VECTOR &&
                   vector <= LAST_LEGACY_VECTOR &&
                   (!smp_processor_id() ||
                    /*
                     * For AMD/Hygon do spurious PIC interrupt
                     * detection on all CPUs, as it has been observed
                     * that during unknown circumstances spurious PIC
                     * interrupts have been delivered to CPUs
                     * different than the BSP.
                     */
                   (boot_cpu_data.x86_vendor & (X86_VENDOR_AMD |
                                                X86_VENDOR_HYGON))) &&
                   bogus_8259A_irq(vector - FIRST_LEGACY_VECTOR)) )
            {

Which I find too complex to read, and prone to mistakes by future
modifications.

What is your reasoning for wanting the smp_processor_id() check in
the caller rather than bogus_8259A_irq()?  It does seem fine to me to
do such check in bogus_8259A_irq(), as whether the IRQ is bogus also
depends on whether it fired on the BSP or any of the APs.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.