From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753580AbdLHXB7 (ORCPT ); Fri, 8 Dec 2017 18:01:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46974 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752610AbdLHXBx (ORCPT ); Fri, 8 Dec 2017 18:01:53 -0500 Date: Fri, 8 Dec 2017 16:01:52 -0700 From: Alex Williamson To: Jacob Pan Cc: Jean-Philippe Brucker , "iommu@lists.linux-foundation.org" , LKML , Joerg Roedel , David Woodhouse , Greg Kroah-Hartman , Rafael Wysocki , Lan Tianyu , Jean Delvare , Will Deacon , "Kumar, Sanjay K" Subject: Re: [PATCH v3 15/16] iommu: introduce page response function Message-ID: <20171208160152.738b2ebd@t450s.home> In-Reply-To: <20171208124017.519120c1@jacob-builder> 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> <20171208124017.519120c1@jacob-builder> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 08 Dec 2017 23:01:53 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 8 Dec 2017 12:40:17 -0800 Jacob Pan wrote: > 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? Yep. Thanks, Alex > /** > * 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; > }; From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [PATCH v3 15/16] iommu: introduce page response function Date: Fri, 8 Dec 2017 16:01:52 -0700 Message-ID: <20171208160152.738b2ebd@t450s.home> 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> <20171208124017.519120c1@jacob-builder> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20171208124017.519120c1@jacob-builder> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Jacob Pan Cc: Lan Tianyu , Greg Kroah-Hartman , Rafael Wysocki , Will Deacon , LKML , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , Jean Delvare , "Kumar, Sanjay K" , David Woodhouse List-Id: iommu@lists.linux-foundation.org On Fri, 8 Dec 2017 12:40:17 -0800 Jacob Pan wrote: > 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? Yep. Thanks, Alex > /** > * 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; > };