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 57DFEC43613 for ; Fri, 21 Jun 2019 18:36:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 343E72083B for ; Fri, 21 Jun 2019 18:36:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726460AbfFUSg0 (ORCPT ); Fri, 21 Jun 2019 14:36:26 -0400 Received: from mga07.intel.com ([134.134.136.100]:32036 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726017AbfFUSg0 (ORCPT ); Fri, 21 Jun 2019 14:36:26 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.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 Cc: Kate Stewart , Peter Zijlstra , Jan Kiszka , Ricardo Neri , Stephane Eranian , Ingo Molnar , Wincy Van , Ashok Raj , x86 , Andi Kleen , Borislav Petkov , "Eric W. Biederman" , "Ravi V. Shankar" , Ricardo Neri , Bjorn Helgaas , Juergen Gross , Tony Luck , Randy Dunlap , LKML , iommu@lists.linux-foundation.org, Philippe Ombredanne , jacob.jun.pan@intel.com 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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 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