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=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 732D1C43613 for ; Fri, 21 Jun 2019 18:36:30 +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 57AF52083B for ; Fri, 21 Jun 2019 18:36:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57AF52083B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=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 E1049130A; Fri, 21 Jun 2019 18:36:29 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BB7E01309 for ; Fri, 21 Jun 2019 18:36:28 +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 AFD8527B for ; Fri, 21 Jun 2019 18:36:26 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2019 11:36:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,401,1557212400"; d="scan'208";a="151340684" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.7.199.155]) by orsmga007.jf.intel.com with ESMTP; 21 Jun 2019 11:36:25 -0700 Date: Fri, 21 Jun 2019 11:39:38 -0700 From: Jacob Pan To: Thomas Gleixner Subject: Re: [RFC PATCH v4 20/21] iommu/vt-d: hpet: Reserve an interrupt remampping table entry for watchdog Message-ID: <20190621113938.1679f329@jacob-builder> In-Reply-To: <20190621103126.585ca6d3@jacob-builder> References: <1558660583-28561-1-git-send-email-ricardo.neri-calderon@linux.intel.com> <1558660583-28561-21-git-send-email-ricardo.neri-calderon@linux.intel.com> <20190619084316.71ce5477@jacob-builder> <20190621103126.585ca6d3@jacob-builder> Organization: OTC X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Cc: Kate Stewart , Peter Zijlstra , Jan Kiszka , Ricardo Neri , Stephane Eranian , Ingo Molnar , Wincy Van , Ashok Raj , x86 , Andi Kleen , Borislav Petkov , jacob.jun.pan@intel.com, "Ravi V. Shankar" , Ricardo Neri , Bjorn Helgaas , Juergen Gross , Tony Luck , Randy Dunlap , LKML , iommu@lists.linux-foundation.org, "Eric W. Biederman" , Philippe Ombredanne 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 Fri, 21 Jun 2019 10:31:26 -0700 Jacob Pan wrote: > On Fri, 21 Jun 2019 17:33:28 +0200 (CEST) > Thomas Gleixner wrote: > > > On Wed, 19 Jun 2019, Jacob Pan wrote: > > > On Tue, 18 Jun 2019 01:08:06 +0200 (CEST) > > > Thomas Gleixner wrote: > > > > > > > > Unless this problem is not solved and I doubt it can be solved > > > > after talking to IOMMU people and studying manuals, > > > > > > I agree. modify irte might be done with cmpxchg_double() but the > > > queued invalidation interface for IRTE cache flush is shared with > > > DMA and requires holding a spinlock for enque descriptors, QI tail > > > update etc. > > > > > > Also, reserving & manipulating IRTE slot for hpet via backdoor > > > might not be needed if the HPET PCI BDF (found in ACPI) can be > > > utilized. But it might need more work to add a fake PCI device for > > > HPET. > > > > What would PCI/BDF solve? > I was thinking if HPET is a PCI device then it can naturally > gain slots in IOMMU remapping table IRTEs via PCI MSI code. Then > perhaps it can use the IRQ subsystem to set affinity etc. w/o > directly adding additional helper functions in IRQ remapping code. I > have not followed all the discussions, just a thought. > I looked at the code again, seems the per cpu HPET code already taken care of HPET MSI management. Why can't we use IR-HPET-MSI chip and domain to allocate and set affinity etc.? Most APIC timer has ARAT not enough per cpu HPET, so per cpu HPET is not used mostly. Jacob _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu