Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4665302ybi; Mon, 3 Jun 2019 15:07:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqwAUDFQ8xEhsOk5OqeUWo+1tjX7W1K5dtnlaC9ez4/3WMeqYwM4xoSsLoGe0IMDBAODJ8J1 X-Received: by 2002:aa7:8c4c:: with SMTP id e12mr24355760pfd.131.1559599625683; Mon, 03 Jun 2019 15:07:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559599625; cv=none; d=google.com; s=arc-20160816; b=oS++Shw/KjoD6pqmJPMVtu2MFipNphw3ef7V2ks6W29v6/UExHNkNGPFfkZ2HFa19E WE3MWcYa6H4FLwIZtZ9SRHNSyysZZJFqZb5XOXZbt6dZE+XcepZQ8zR2g+sKYS0bzfD3 hhC0Yf+l7rZ7TRfwBiaKtxM0squ2upGSUT4qc35Zp/wspwSyxq443njFihy51XiAoRCF YQD8H6LcMG1Mqb9AWbfEMISNNgiJVMOxM+BnJuzNZ+AT8SoT3qn95ygWbbcL7337mBC9 tZfx38AqLKAUeo+dk9XT6kpay5HJmFkcdFwwQflOBTn5Uxz747zX81yM/kwFZ3ZtmvIB vC4A== 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; bh=/9vf/1+dr3OE8DUq7UfJJwxqwth/Y65R8PhS/ibviU8=; b=DGqZUdFOeyyVr22kAP1NvjRZPBzlCBAyrORhuuRl+o8sjruNFoXbmcWgWzeTF2Uwu1 yGprNV0t/iT1GccoDoauUJIiquhISwXBLVPcOhWg/LUFcPjmEehtvHXTSesUegWEUrOW wTie2Otzr35p6gI7gnCh4qb370zrZd2780hyPq4loYaX0f2Jev0lI5zE1evlJJRSh8Xg yeKgD9PouDfjk8Vk00DK3VPaXCDMEyyarlr7gu8CYxKUCr1DJ4F2kh+alkPxsf+tCsMz W6uJmOFDnt5aCY/5ycK4ya9wsCHpOaodcwaRcxBJusbPicsISAPcDv272vtzjYchD5Ji YpJw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p5si20040791pls.431.2019.06.03.15.06.49; Mon, 03 Jun 2019 15:07:05 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726858AbfFCWFm (ORCPT + 99 others); Mon, 3 Jun 2019 18:05:42 -0400 Received: from mga11.intel.com ([192.55.52.93]:1031 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726205AbfFCWFj (ORCPT ); Mon, 3 Jun 2019 18:05:39 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jun 2019 15:05:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,548,1549958400"; d="scan'208";a="181310106" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.7.199.155]) by fmsmga002.fm.intel.com with ESMTP; 03 Jun 2019 15:05:38 -0700 Date: Mon, 3 Jun 2019 15:08:42 -0700 From: Jacob Pan To: Jean-Philippe Brucker Cc: joro@8bytes.org, alex.williamson@redhat.com, eric.auger@redhat.com, ashok.raj@intel.com, yi.l.liu@intel.com, robdclark@gmail.com, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, robin.murphy@arm.com, jacob.jun.pan@linux.intel.com Subject: Re: [PATCH v2 2/4] iommu: Introduce device fault data Message-ID: <20190603150842.11070cfd@jacob-builder> In-Reply-To: <20190603145749.46347-3-jean-philippe.brucker@arm.com> References: <20190603145749.46347-1-jean-philippe.brucker@arm.com> <20190603145749.46347-3-jean-philippe.brucker@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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 3 Jun 2019 15:57:47 +0100 Jean-Philippe Brucker wrote: > +/** > + * struct iommu_fault_page_request - Page Request data > + * @flags: encodes whether the corresponding fields are valid and > whether this > + * is the last page in group (IOMMU_FAULT_PAGE_REQUEST_* > values) > + * @pasid: Process Address Space ID > + * @grpid: Page Request Group Index > + * @perm: requested page permissions (IOMMU_FAULT_PERM_* values) > + * @addr: page address > + * @private_data: device-specific private information > + */ > +struct iommu_fault_page_request { > +#define IOMMU_FAULT_PAGE_REQUEST_PASID_VALID (1 << 0) > +#define IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE (1 << 1) > +#define IOMMU_FAULT_PAGE_REQUEST_PRIV_DATA (1 << 2) > + __u32 flags; > + __u32 pasid; > + __u32 grpid; > + __u32 perm; > + __u64 addr; > + __u64 private_data[2]; > +}; > + Just a thought, for non-identity G-H PASID management. We could pass on guest PASID in PRQ to save a lookup in QEMU. In this case, QEMU allocate a GPASID for vIOMMU then a host PASID for pIOMMU. QEMU has a G->H lookup. When PRQ comes in to the pIOMMU with HPASID, IOMMU driver can retrieve GPASID from the bind data then report to the guest via VFIO. In this case QEMU does not need to do a H->G PASID lookup. Should we add a gpasid field here? or we can add a flag and field later, up to you. Thanks, Jacob