[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.
|