Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1063712ybi; Fri, 21 Jun 2019 13:06:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqzh0aGwUSDX9pCyLIIUZ+VIiSP5rIkO903FXSFwjAEsN1/YupQ6uiTTeqcAF5B0koJIXCP1 X-Received: by 2002:a17:90a:22c6:: with SMTP id s64mr9050559pjc.5.1561147577992; Fri, 21 Jun 2019 13:06:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561147577; cv=none; d=google.com; s=arc-20160816; b=VaHYWsn83h5qBLJCdmGpnavYpXQDGDVL5wTOwXjIwXpqcQInqP4zz9BOcTAcVexhWa dy3UgPpw2Jsro5bwSUh73BnYuPGvgzAeqS3nkUW3xqyl8teQVAT2xNcOmScT1UaoLiHV yqpbJlfyNz/dc4eB1ZDHRJip7CRzra9O6e/kczryYkmNok8ka8Mec3efU/EAQdq3e+qi gTE+aLZB9Ny8x6Xc5Cz1nelRFFiARtQaVM/bXYIswvt8QHnKxesRVxB7xymJUNh3Bb1I QPkAjGZQyAexwDI/sTdoKDx8PzyKqgPfk5b2iuukW4G0Js7k1LsNMrKCD42V6DLc1OQA VJTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=K1RG1bEQqxVg65w+69smGHe/3xpU1HpSGwMr+7EqZXk=; b=irFlkw2rdkZaDF9OI+OO32tD+7EEfd13eC5kj7WIyGuw5sdhs6Dkt6O1LJauVacJEt DhoU0GfSa82RHgqB0beo9/kqlSivPXGPbfBo3TA8FXG68GmcokTVs0pvb8/juehEHGaP HXq+pZ3tws7V65XYkMnIsClHT2Su5ewoTW+SqVTkHPAzm6kgpLZqJZUxZ16lfL2RbHhb hNjJHzsRq7OgoefrPJ/Txz0dG+6NtI2pbyU62EV5PbHulDjUrwzUyXSkcPP+7JW4Llhc 3yOhGli1lMA4S9tmqEOMRIuB3HlRcLfoZEtiXbKjlPU7iPVEjpBoawXk5ByQF2pV6YUi 5Vmw== 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 e21si3304030pgv.310.2019.06.21.13.06.02; Fri, 21 Jun 2019 13:06:17 -0700 (PDT) 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 S1726190AbfFUUFh (ORCPT + 99 others); Fri, 21 Jun 2019 16:05:37 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:56966 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725985AbfFUUFh (ORCPT ); Fri, 21 Jun 2019 16:05:37 -0400 Received: from p5b06daab.dip0.t-ipconnect.de ([91.6.218.171] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hePmQ-00060Y-Lz; Fri, 21 Jun 2019 22:05:02 +0200 Date: Fri, 21 Jun 2019 22:05:01 +0200 (CEST) From: Thomas Gleixner To: Jacob Pan 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 Subject: Re: [RFC PATCH v4 20/21] iommu/vt-d: hpet: Reserve an interrupt remampping table entry for watchdog In-Reply-To: <20190621113938.1679f329@jacob-builder> Message-ID: 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> <20190621113938.1679f329@jacob-builder> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 On Fri, 21 Jun 2019, Jacob Pan wrote: > 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. Sure, we can use that, but that does not allow to move the affinity from NMI context either. Same issue with the IOMMU as with the other hack. Thanks, tglx