From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 695C6C31E4A for ; Fri, 14 Jun 2019 01:15:17 +0000 (UTC) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3BED8217D7 for ; Fri, 14 Jun 2019 01:15:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3BED8217D7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id D7088E39; Fri, 14 Jun 2019 01:15:16 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 76375E20 for ; Fri, 14 Jun 2019 01:15:15 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0D1D2E5 for ; Fri, 14 Jun 2019 01:15:14 +0000 (UTC) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2019 18:15:14 -0700 X-ExtLoop1: 1 Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orsmga005.jf.intel.com with ESMTP; 13 Jun 2019 18:15:13 -0700 Date: Thu, 13 Jun 2019 18:14:54 -0700 From: Ricardo Neri To: Thomas Gleixner Subject: Re: [RFC PATCH v4 05/21] x86/hpet: Reserve timer for the HPET hardlockup detector Message-ID: <20190614011454.GA6347@ranerica-svr.sc.intel.com> References: <1558660583-28561-1-git-send-email-ricardo.neri-calderon@linux.intel.com> <1558660583-28561-6-git-send-email-ricardo.neri-calderon@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Cc: Kate Stewart , "Ravi V. Shankar" , x86@kernel.org, Ashok Raj , Arnd Bergmann , Peter Zijlstra , Philippe Ombredanne , Randy Dunlap , Clemens Ladisch , linux-kernel@vger.kernel.org, Stephane Eranian , Ricardo Neri , "Rafael J. Wysocki" , iommu@lists.linux-foundation.org, Tony Luck , "H. Peter Anvin" , Andi Kleen , Borislav Petkov , Ingo Molnar X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iommu-bounces@lists.linux-foundation.org Errors-To: iommu-bounces@lists.linux-foundation.org On Tue, Jun 11, 2019 at 09:54:25PM +0200, Thomas Gleixner wrote: > On Thu, 23 May 2019, Ricardo Neri wrote: > > > HPET timer 2 will be used to drive the HPET-based hardlockup detector. > > Reserve such timer to ensure it cannot be used by user space programs or > > for clock events. > > > > When looking for MSI-capable timers for clock events, skip timer 2 if > > the HPET hardlockup detector is selected. > > Why? Both the changelog and the code change lack an explanation why this > timer is actually touched after it got reserved for the platform. The > reservation should make it inaccessible for other things. hpet_reserve_platform_timers() will give the HPET char driver a data structure which specifies which drivers are reserved. In this manner, they cannot be used by applications via file opens. The timer used by the hardlockup detector should be marked as reserved. Also, hpet_msi_capability_lookup() populates another data structure which is used when obtaining an unused timer for a HPET clock event. The timer used by the hardlockup detector should not be included in such data structure. Is this the explanation you would like to see? If yes, I will include it in the changelog. Thanks and BR, Ricardo _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu