Received: by 10.192.165.148 with SMTP id m20csp3331600imm; Mon, 23 Apr 2018 04:55:00 -0700 (PDT) X-Google-Smtp-Source: AIpwx49vXqQm2FhFuGuPzPMd5PSr8eNDk6bBT5CeijPyHw/opRtjKFXhst+FYNuh1CiH18ytnInu X-Received: by 10.98.192.80 with SMTP id x77mr18435234pff.67.1524484500879; Mon, 23 Apr 2018 04:55:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524484500; cv=none; d=google.com; s=arc-20160816; b=PdLVx+GSyny7dyx+RSf8erkTgZcpwmVBX8kf4+ofFaDFczaNnv1Lzzvf0aykzrbjoQ axvACb+JkqhjruFEoodi+okGYJiQy1vu96Gguj3kJ4stGT7v3IA/3DUWhdLVtTkny+RU 0+yAkF8ZFbjrVKYQQgk04hpeVufHKxo+gmAKpdsbZE++Q9eT8ql7nrXC7XxMk/0pXJGj Iyd09eM+m4N6J/ZhQ7ZMM8vxxCRkfc0ueZEWMKJ9xYCBYySelScGFdWUOBPDCAcYxmCS FK/ZnwHv0h7q2BDvaVe3sQpPR5hl/UJ4wL20rSFYD2LJBXgvCGISsmg/YFGMHnGrrGbZ v9ZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=ZhJccs8j7zF2RwIOrs0vXDsTsAv5ZhUumFBDZEosT5o=; b=Td7HkFT3w9lmD+sWjqh/gJOcG0UBXh6FC9Hrjd9a4ePMHepzRiHEWNg/is3qHau3I8 DdqLbdcSaVwY8A/2+vw7d8CYwhckCut+cJtPJp9vXNZ05JviYm1R/T+abuVfGSJJ9wci Y0eE7k9TOwq8ajHPHkHuKDAX7DwpNjoQuEnvzp6hbzz72MM5Oih7JtHRdz61blKEUU+R EAQCEOWtKIogSQ6xD+j7qA5E1eUaiu9woYBDBP7yDN/5+RnpPTtwhIeaOh9jzMbGWrBC Ztv7MUhcen1sAUBwPo4GBMiDjXhLKS9w4R5xuJPl0U0FCBQKENQBP7aJyeBU/K0/NEqu n3dQ== 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 f34-v6si11195402ple.52.2018.04.23.04.54.46; Mon, 23 Apr 2018 04:55:00 -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 S1754935AbeDWLwX (ORCPT + 99 others); Mon, 23 Apr 2018 07:52:23 -0400 Received: from mga17.intel.com ([192.55.52.151]:16874 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754710AbeDWLwU (ORCPT ); Mon, 23 Apr 2018 07:52:20 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Apr 2018 04:52:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,318,1520924400"; d="scan'208";a="36317672" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.7.199.155]) by orsmga006.jf.intel.com with ESMTP; 23 Apr 2018 04:52:19 -0700 Date: Mon, 23 Apr 2018 04:54:53 -0700 From: Jacob Pan To: Jean-Philippe Brucker Cc: "iommu@lists.linux-foundation.org" , LKML , Joerg Roedel , David Woodhouse , Greg Kroah-Hartman , Alex Williamson , Rafael Wysocki , "Liu, Yi L" , "Tian, Kevin" , Raj Ashok , Jean Delvare , Christoph Hellwig , Lu Baolu , Yi L , jacob.jun.pan@linux.intel.com Subject: Re: [PATCH v4 10/22] iommu: introduce device fault data Message-ID: <20180423045453.752f8169@jacob-builder> In-Reply-To: <20180423101140.GA38106@ostrya.localdomain> References: <1523915351-54415-1-git-send-email-jacob.jun.pan@linux.intel.com> <1523915351-54415-11-git-send-email-jacob.jun.pan@linux.intel.com> <20180423101140.GA38106@ostrya.localdomain> 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 Mon, 23 Apr 2018 11:11:41 +0100 Jean-Philippe Brucker wrote: > On Mon, Apr 16, 2018 at 10:48:59PM +0100, Jacob Pan wrote: > > +/** > > + * 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 > > You can remove @rid from the comment > thanks, will do. > > + * @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. > > In my opinion you can remove @iommu_private entirely. I proposed this > field so that the IOMMU driver can store fault metadata when reporting > them, and read them back when completing the fault. I'm not using it > in SMMUv3 anymore (instead re-fetching the metadata) and it can't be > used anyway, because the value isn't copied into page_response_msg. > In vt-d use, I use private data for preserving vt-d specific fault data across request and response. e.g. vt-d has streaming response type in addition to group response (standard). This way, generic code does not need to know about it. At device level, since we have to sanitize page response based on pending page requests, I am doing the private data copy in iommu.c, in the pending event list. > Thanks, > Jean > > > + */ > > +struct iommu_fault_event { > > + enum iommu_fault_type type; > > + enum iommu_fault_reason reason; > > + u64 addr; > > + u32 pasid; > > + u32 page_req_group_id; > > + u32 last_req : 1; > > + u32 pasid_valid : 1; > > + u32 prot; > > + u64 device_private; > > + u64 iommu_private; > > +}; [Jacob Pan]