Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7600562ybl; Thu, 16 Jan 2020 02:24:37 -0800 (PST) X-Google-Smtp-Source: APXvYqyhelrvIRB+5y/ixaLhKnmLheDKaEm4CXK1beCTHTHOtYUIL/hRKUf+h+EvjUIgYMb2M2kx X-Received: by 2002:a54:468b:: with SMTP id k11mr3423025oic.134.1579170277063; Thu, 16 Jan 2020 02:24:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579170277; cv=none; d=google.com; s=arc-20160816; b=YGnrSBYb79nuKb2nqvQleY8ScYIw1o7zdgqRs3H7IelgLtFzSKwdZNZ6c6+PlB3Nct 47uygRIIzdNoYkYyjMph0f4s2zWj1TwevseAq/NBxT9nny+NM3AehGghhpwdL0z0PW5A zFrFJJ6AMjTWQ/033SVe+2KPz8EtlJqFM4prGLAqdY31yUaxEa8AWBcAroTr8F2Ff8M8 ZT6HsULuXeB3Jw6fS2JGHaWQsVQ9S3I+YkAipHWZvxrvRC36D8ewqweCHJwyYNud1g9X K4GN0W5lSpemY7GAVIwekjP7ZWYuBTCykvVlzwyAmex555tH6BhpeMglm4wesMW8BSmQ 2jiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=E9A9ebUnZxksNTQzMGkKUererbhVKv4YtsgB8tvTFL8=; b=MXakia1r9KsDd8fNx46umpOiH5cPzhtw9XzJpfbop/ib9aEJOjmCBA2NatejP+YSD7 pDDsJZOqNJLuEsmmExoI7hE4mEJyBOerFHWqF4aVtMG8pwBWxIoz4XRjRADmloRnxVZP lPyifDBEjdp1t2JGpHLveWF34GrM0cMSQiv8F4EcFq4lbzKJaclnjGBTJw0ARKa24F/9 4WpSSwWRRWThhruGuHMgOn47wTDesvdeWifQNINuGR8iIiU8T6Wvvlhx7BsxGuSY1DgP NcKr2uB8XjR/1cr1q40SAcO8aPeyBz9zVrkefkp0ljPoZAh9r01e3R6ZbVo/6e4twsoR bcnQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d192si11226655oig.21.2020.01.16.02.24.24; Thu, 16 Jan 2020 02:24:37 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732442AbgAPKCH (ORCPT + 99 others); Thu, 16 Jan 2020 05:02:07 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:51044 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732419AbgAPKCD (ORCPT ); Thu, 16 Jan 2020 05:02:03 -0500 Received: from p5b06da22.dip0.t-ipconnect.de ([91.6.218.34] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1is1yK-0003KK-V9; Thu, 16 Jan 2020 11:01:53 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 6AE3E100C1E; Thu, 16 Jan 2020 11:01:52 +0100 (CET) From: Thomas Gleixner To: Kar Hin Ong , Bjorn Helgaas Cc: linux-rt-users , LKML , "x86\@kernel.org" , "linux-pci\@vger.kernel.org" , "H. Peter Anvin" , Dave Hansen , Julia Cartwright , Keng Soon Cheah , Gratian Crisan , Peter Zijlstra Subject: RE: RE: Re: "oneshot" interrupt causes another interrupt to be fired erroneously in Haswell system In-Reply-To: References: <20191031230532.GA170712@google.com> <87a76oxqv1.fsf@nanos.tec.linutronix.de> Date: Thu, 16 Jan 2020 11:01:52 +0100 Message-ID: <87muanwwhb.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Kar Hin Ong writes: >> I don't have access to the document you mentioned, but I know that chipsets >> have a knob to control that behaviour. Just checked a few chipset docs and they >> contain the same sentence, but then in the next paragraph they say: >> >> "If the I/OxAPIC entry is masked (via the mask bit in the corresponding >> Redirection Table Entry), then the corresponding PCI Express >> interrupt(s) is forwarded to the legacy ICH, provided the Disable PCI >> INTx Routing to ICH bit is clear, Section 19.10.2.27, QPIPINTRC: Intel >> QuickPath Interconnect Protocol Interrupt Control." >> >> That control bit is 0 after reset, so the legacy forwarding works. > > Intel support engineer do provide similar advice to us as a workaround > to the CPU behaviour. They said we could enable the "Don'tRouteToPCH" > bit in the BIOS to block the interrupt from propagating to PCH. This > bit is located at "Coherent Interface Protocol Interrupt Control > (cipintrc)" register of "Virtualization" device (Bus 0, Device 5, > Function 0, Offset 0x14C). > > With the help of our BIOS engineer, after setting this bit in BIOS > does prevent the interrupt forwarding. > > However, Intel told us that this workaround is not validated, i.e. the > side effect of setting this bit is unknown. What? That's ridiculous. That bit is documented in various chipset documents and that legacy rerouting is really just there to support OSes which do not support multiple IO-APICs properly. If setting this bit has unknown side effects then someone at Intel should have a close look and fix their documentation. Can the Intel people on Cc please take care of this? As we have already quirks in drivers/pci/quirks.c which handle the same issue on older chipsets, we really should add one for these kind of systems to avoid fiddling with the BIOS (which you can, but most people cannot). Thanks, tglx