Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp636297ybl; Thu, 23 Jan 2020 05:10:21 -0800 (PST) X-Google-Smtp-Source: APXvYqzQyKp1hQL+ve+AnyZdm+ou/J8p4hZH+CHxrjVPo76aT/VS/j7+bxqc7Em6EEWu6fDL3Gap X-Received: by 2002:a05:6830:4d9:: with SMTP id s25mr11411727otd.171.1579785020840; Thu, 23 Jan 2020 05:10:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579785020; cv=none; d=google.com; s=arc-20160816; b=A6uixtAM/UzNNAAm8O94Lo/jbWLvGSE/cnnbPT48yuF4iCcrtJXfZU/w14nGiu/0SL ahC/k2lR7EqFw1KQKB+CU/4giYqsTDUVWNXiQ8Eek1mqjExVGRSeLb72RMdbR1+5YENj fikSudGR9mJy8kXcNBlM5BH6i6MZN6kz1KvWvKNUUNMxHs+HbVAEFm8p4G6uUUoZFl0K 84dVrCg4AaE49II461uiooRFDuCNj+46yJlPCnXXuuXh6VgEXJy4IripCOkk9UkUneoQ qPwaVJouwD46+hraCTp/cMf/k+6Oqw3V+wDMuYvjm83yl40VuEFnPTJu62c32KpPvKHu WXXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:references:in-reply-to:subject:cc:to:from; bh=V68D2njQigS9bmjDBoiUiyov4G0+J0QSkUmoaTKz9mk=; b=V/VxGacq614fU2y4FzQ4Gq+mxF1MGvipMPPeY+02QwzCSMUTDd+LaWxCm4IfwyD8IV 3ULZbopNm/RvnZId4GMOlVWDaSOkbuLaE3YgqlqWicmiEp8ww4FKUBSYk3yr5sYlWzPp F9M9rPlOIffjLzarVhPPGzwB+Fp40zMbhbjSJrxV0MUr9Xuh6BlAEjLl4FMUgY2Ane06 Rf7+5Ys7xEvMxUWr9X+r16rrXcYyaiRZZF/0VBfmFz35SxUiU7XGFW8xv+vFXKhYXrOd EEIqaeXv0Zggot3Fi0o4oZrx0+G7+m5g3XoOQ3ZoQPrnrqJsEJ3YLwMQrVfot96GmjrN qyNQ== 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 n11si1024114otq.112.2020.01.23.05.10.07; Thu, 23 Jan 2020 05:10:20 -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 S1726871AbgAWNJG convert rfc822-to-8bit (ORCPT + 99 others); Thu, 23 Jan 2020 08:09:06 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:39975 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726170AbgAWNJF (ORCPT ); Thu, 23 Jan 2020 08:09:05 -0500 Received: from [5.158.153.53] (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 1iucEA-00006a-Ow; Thu, 23 Jan 2020 14:08:54 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 692DD1017FA; Thu, 23 Jan 2020 14:08:54 +0100 (CET) From: Thomas Gleixner To: sean.v.kelley@linux.intel.com, 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: <8f1e5981b519acb5edf53b5392c81ef7cbf6a3eb.camel@linux.intel.com> References: <20191031230532.GA170712@google.com> <87a76oxqv1.fsf@nanos.tec.linutronix.de> <87muanwwhb.fsf@nanos.tec.linutronix.de> <8f1e5981b519acb5edf53b5392c81ef7cbf6a3eb.camel@linux.intel.com> Date: Thu, 23 Jan 2020 14:08:54 +0100 Message-ID: <87muaetj4p.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT 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 Sean, Sean V Kelley writes: > I looked into it Thomas. The issue is as you suggested early in the > thread. If an IRQ arrives at line N of a non-primary IO-APIC and that > line is masked, a new IRQ is generated on the primary IO-APIC/PIC. > > The BIOS setting to address this forwarding is as above Disable INTx > Route to PCH/ICH/SouthBridge. When this bit is set, local INTx messages > received from the PCI-E ports are not routed to legacy PCH - they are > either converted into MSI via the integrated I/OxAPIC (if the I/OxAPIC > mask bit is clear in the appropriate entries) or cause no further > action (when mask bit is set). > > This capability is tested and supported fully on Intel platforms. Thanks for the confirmation. > Once you get to SKX/CLX things change and integrated IOxAPICs in the > IIO module convert legacy PCI Express interrupt messages into MSI > interrupts directly. Beyond SKX/CLX there are no longer IOxAPICs in > IIO. IOxAPIC is only in the PCH. Devices connected to the > IIO will use native MSI/MSI-x mechanisms. > > The problem is with the absolute lack of useful documentation. That’s > not acceptable. Yeah. > You recall the work Olaf and Stefan did at SuSE ten years ago (?) on > boot irq quirks and the amount of research they had to do it learn > about the behavior.[4] Oh yes. > From a Real-Time Linux perspective this is really important to me. As > we get closer to fully mainlined we need to have this information > readily available with greater usage of threaded irqs in combination > with legacy interrupts on the older platforms. > > So I will ensure we actually create useful information pointing to this > behavior either in kernel docs or online as in a white paper or both. Great. >> 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). > Agreed, and I will follow-up with Kar Hin Ong to get them added. Much appreciated. Thanks, tglx