From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753493AbdKXMAj (ORCPT ); Fri, 24 Nov 2017 07:00:39 -0500 Received: from foss.arm.com ([217.140.101.70]:42724 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753442AbdKXMAh (ORCPT ); Fri, 24 Nov 2017 07:00:37 -0500 From: Jean-Philippe Brucker Subject: Re: [PATCH v3 08/16] iommu: introduce device fault data To: Jacob Pan , "iommu@lists.linux-foundation.org" , LKML , Joerg Roedel , David Woodhouse , Greg Kroah-Hartman , Rafael Wysocki , Alex Williamson Cc: Lan Tianyu , Yi L , "Liu@mail.linuxfoundation.org" , Jean Delvare References: <1510944914-54430-1-git-send-email-jacob.jun.pan@linux.intel.com> <1510944914-54430-9-git-send-email-jacob.jun.pan@linux.intel.com> Message-ID: <65b76897-55b8-6f0c-e103-4337254041ca@arm.com> Date: Fri, 24 Nov 2017 12:03:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1510944914-54430-9-git-send-email-jacob.jun.pan@linux.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jacob, On 17/11/17 18:55, Jacob Pan wrote: > Device faults detected by IOMMU can be reported outside IOMMU > subsystem for further processing. This patch intends to provide > a generic device fault data such that device drivers can be > communicated with IOMMU faults without model specific knowledge. > > The proposed format is the result of discussion at: > https://lkml.org/lkml/2017/11/10/291 > Part of the code is based on Jean-Philippe Brucker's patchset > (https://patchwork.kernel.org/patch/9989315/). > > The assumption is that model specific IOMMU driver can filter and > handle most of the internal faults if the cause is within IOMMU driver > control. Therefore, the fault reasons can be reported are grouped > and generalized based common specifications such as PCI ATS. > > Signed-off-by: Jacob Pan > Signed-off-by: Liu, Yi L > Signed-off-by: Ashok Raj This looks good from my point of view. And since it's not UAPI, we can always update it if it turns out that device drivers need more information. [...] > +/** > + * struct iommu_fault_event - Generic per device fault data > + * > + * - PCI and non-PCI devices > + * - Recoverable faults (e.g. page request), information based on PCI ATS > + * and PASID spec. > + * - Un-recoverable faults of device interest > + * - DMA remapping and IRQ remapping faults > + > + * @type contains fault type. > + * @reason fault reasons if relevant outside IOMMU driver, IOMMU driver internal > + * faults are not reported > + * @addr: tells the offending page address > + * @pasid: contains process address space ID, used in shared virtual memory(SVM) > + * @rid: requestor ID This comment can be removed Thanks, Jean > + * @page_req_group_id: page request group index > + * @last_req: last request in a page request group > + * @pasid_valid: indicates if the PRQ has a valid PASID > + * @prot: page access protection flag, e.g. IOMMU_FAULT_READ, IOMMU_FAULT_WRITE > + * @device_private: if present, uniquely identify device-specific > + * private data for an individual page request. > + * @iommu_private: used by the IOMMU driver for storing fault-specific > + * data. Users should not modify this field before > + * sending the fault response. > + */ > +struct iommu_fault_event { > + enum iommu_fault_type type; > + enum iommu_fault_reason reason; > + u64 addr; > + u32 pasid; > + u32 page_req_group_id : 9; > + u32 last_req : 1; > + u32 pasid_valid : 1; > + u32 prot; > + u64 device_private; > + u64 iommu_private; > +};