From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753656AbdKMQLK (ORCPT ); Mon, 13 Nov 2017 11:11:10 -0500 Received: from mga02.intel.com ([134.134.136.20]:47580 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753425AbdKMQLG (ORCPT ); Mon, 13 Nov 2017 11:11:06 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,389,1505804400"; d="scan'208";a="173001862" Date: Mon, 13 Nov 2017 08:12:04 -0800 From: Jacob Pan To: Jean-Philippe Brucker Cc: "Liu, Yi L" , "iommu@lists.linux-foundation.org" , LKML , Joerg Roedel , David Woodhouse , Greg Kroah-Hartman , "Wysocki, Rafael J" , "Lan, Tianyu" , "Tian, Kevin" , "Raj, Ashok" , Alex Williamson , jacob.jun.pan@linux.intel.com Subject: Re: [PATCH v2 08/16] iommu: introduce device fault data Message-ID: <20171113081204.4b2b8516@jacob-builder> In-Reply-To: <6ffb6485-669d-aecb-3088-9a5ef7563840@arm.com> References: <1507244624-39189-1-git-send-email-jacob.jun.pan@linux.intel.com> <1507244624-39189-9-git-send-email-jacob.jun.pan@linux.intel.com> <439401c0-a9ff-a69a-dc10-12d72f7abbab@arm.com> <09d451dc-c0e9-1fa2-8f85-45a9b1185d48@arm.com> <20171109113629.6a9251a4@jacob-builder> <0ed3e52b-2ca7-e378-817b-34b517a392da@arm.com> <20171110160036.147d064e@jacob-builder> <6ffb6485-669d-aecb-3088-9a5ef7563840@arm.com> 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 13 Nov 2017 13:19:50 +0000 Jean-Philippe Brucker wrote: > On 11/11/17 00:00, Jacob Pan wrote: > > On Fri, 10 Nov 2017 13:54:59 +0000 > > Jean-Philippe Brucker wrote: > > > >> /* > >> * Note: I tried to synthesize what I believe would be useful to > >> device > >> * drivers and guests, with regards to the kind of faults that the > >> ARM > >> * SMMU is capable of reporting. Other IOMMUs may report more or > >> less > >> * fault reasons, and I guess one should try to associate the > >> faults > >> * reason that matches best a generic one when reporting a fault. > >> * > >> * Finer reason granularity is probably not useful to anyone, and > >> * coarser granularity would require more work from intermediate > >> * components processing the fault to figure out what happened, > >> whose > >> * fault it actually is and where to route it (process vs. device > >> driver > >> * vs. vIOMMU driver misprogamming tables). > >> */ > >> enum iommu_fault_reason { > >> IOMMU_FAULT_REASON_UNKNOWN = 0, > >> > > can we add one for iommu internal error, the specifics may not be > > useful for the device drivers, but it is good to know iommu is > > faulting, perhaps can take action that inform driver users. > > i.e. > > /* IOMMU internal error, no specific reason to report out */ > > IOMMU_FAULT_REASON_INTERNAL, > > Yes, and maybe it should replace IOMMU_FAULT_REASON_UNKNOWN, since the > device driver would probably handle it the same way. I guess the > INTERNAL fault is always fatal, meaning that the IOMMU is shutting > down and there is no hope to recover? I can't see a good reason to > inform users of non-fatal internal faults, the IOMMU driver will > print those to dmesg and keep going. For fatal faults we're telling > users to stop issuing transactions so the IOMMU driver doesn't get > flooded by events, for example. > Internal faults are not always fatal in vt-d, e.g. programming reserved bits, though it should fail in the first place when programming it synchronously as the code does today. I agree we put all internal faults under IOMMU_FAULT_REASON_INTERNAL, no more UNKNOWN, it is ambiguous in that unknown to device but known to iommu.