From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752730AbdLHUjH (ORCPT ); Fri, 8 Dec 2017 15:39:07 -0500 Received: from mga02.intel.com ([134.134.136.20]:56432 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752527AbdLHUjE (ORCPT ); Fri, 8 Dec 2017 15:39:04 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,378,1508828400"; d="scan'208";a="10781069" Date: Fri, 8 Dec 2017 12:40:17 -0800 From: Jacob Pan To: Jean-Philippe Brucker Cc: Alex Williamson , "iommu@lists.linux-foundation.org" , LKML , Joerg Roedel , David Woodhouse , Greg Kroah-Hartman , Rafael Wysocki , Lan Tianyu , Jean Delvare , Will Deacon , "Kumar, Sanjay K" , jacob.jun.pan@linux.intel.com Subject: Re: [PATCH v3 15/16] iommu: introduce page response function Message-ID: <20171208124017.519120c1@jacob-builder> In-Reply-To: References: <1510944914-54430-1-git-send-email-jacob.jun.pan@linux.intel.com> <1510944914-54430-16-git-send-email-jacob.jun.pan@linux.intel.com> <93661c1c-2d3b-295f-0b9d-52e50ea9e1d0@arm.com> <20171204133715.50c45136@jacob-builder> <20171206112521.1edf8e9b@jacob-builder> <20171207145121.23b3f26f@t450s.home> 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 Fri, 8 Dec 2017 13:52:00 +0000 Jean-Philippe Brucker wrote: > On 07/12/17 21:51, Alex Williamson wrote: > >> Agree, IOMMU driver cannot enforce it. I think VFIO layer can make > >> sure page response come from the assigned device and its > >> guest/container. > > > > Can we enforce it via the IOMMU/VFIO interface? If the response is > > for a struct device, and not an rid/did embedded in a structure, > > then vfio can pass it through w/o worrying about it, ie. response > > comes in via ioctl with association to vfio device fd -> struct > > vfio_device -> struct device, iommu driver fills in rid/did. > > Thanks, > > Yes that's probably the best way, reporting faults and receiving > responses on the device fd. > Just to put these ideas in to code. The IOMMU API used by VFIO has struct device* (derived from fd), no did/rid (to be derived from struct device by IOMMU driver.) int intel_iommu_page_response(struct iommu_domain *domain, struct device *dev, struct page_response_msg *msg) IOMMU driver can further sanitize by checking whether this is a pending page request for the device, and refcount outstanding PRQs. Does it sound right? /** * Generic page response information based on PCI ATS and PASID spec. * @addr: servicing page address * @pasid: contains process address space ID, used in shared virtual memory(SVM) * @resp_code: response code * @page_req_group_id: page request group index * @type: group or stream/single page response * @private_data: uniquely identify device-specific private data for an * individual page response */ struct page_response_msg { u64 addr; u32 pasid; u32 resp_code:4; #define IOMMU_PAGE_RESP_SUCCESS 0 #define IOMMU_PAGE_RESP_INVALID 1 #define IOMMU_PAGE_RESP_FAILURE 0xF u32 pasid_present:1; u32 page_req_group_id : 9; enum page_response_type type; u32 private_data; };