[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171208124017.519120c1@jacob-builder>
Date: Fri, 8 Dec 2017 12:40:17 -0800
From: Jacob Pan <jacob.jun.pan@...ux.intel.com>
To: Jean-Philippe Brucker <jean-philippe.brucker@....com>
Cc: Alex Williamson <alex.williamson@...hat.com>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Joerg Roedel <joro@...tes.org>,
David Woodhouse <dwmw2@...radead.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rafael Wysocki <rafael.j.wysocki@...el.com>,
Lan Tianyu <tianyu.lan@...el.com>,
Jean Delvare <khali@...ux-fr.org>,
Will Deacon <Will.Deacon@....com>,
"Kumar, Sanjay K" <sanjay.k.kumar@...el.com>,
jacob.jun.pan@...ux.intel.com
Subject: Re: [PATCH v3 15/16] iommu: introduce page response function
On Fri, 8 Dec 2017 13:52:00 +0000
Jean-Philippe Brucker <jean-philippe.brucker@....com> 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;
};
Powered by blists - more mailing lists