From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751792AbdLGVvX (ORCPT ); Thu, 7 Dec 2017 16:51:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37356 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750947AbdLGVvW (ORCPT ); Thu, 7 Dec 2017 16:51:22 -0500 Date: Thu, 7 Dec 2017 14:51:21 -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: <20171207145121.23b3f26f@t450s.home> In-Reply-To: <20171206112521.1edf8e9b@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> 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]); Thu, 07 Dec 2017 21:51:22 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 6 Dec 2017 11:25:21 -0800 Jacob Pan wrote: > On Tue, 5 Dec 2017 17:21:15 +0000 > Jean-Philippe Brucker wrote: > > > Hi Jacob, > > > > On 04/12/17 21:37, Jacob Pan wrote: > > > On Fri, 24 Nov 2017 12:03:50 +0000 > > > Jean-Philippe Brucker wrote: > > > > > >> On 17/11/17 18:55, Jacob Pan wrote: > > >>> When nested translation is turned on and guest owns the > > >>> first level page tables, device page request can be forwared > > >>> to the guest for handling faults. As the page response returns > > >>> by the guest, IOMMU driver on the host need to process the > > >>> response which informs the device and completes the page request > > >>> transaction. > > >>> > > >>> This patch introduces generic API function for page response > > >>> passing from the guest or other in-kernel users. The definitions > > >>> of the generic data is based on PCI ATS specification not limited > > >>> to any vendor.> > > >>> Signed-off-by: Jacob Pan > > [...] > > > I think the simpler interface works for in-kernel driver use case > > > very well. But in case of VFIO, the callback function does not turn > > > around send back page response. The page response comes from guest > > > and qemu, where they don;t keep track of the the prq event data. > > > > Is it safe to trust whatever response the guest or userspace gives > > us? The answer seems fairly vendor- and device-specific so I wonder > > if VFIO or IOMMU shouldn't do a bit of sanity checking somewhere, and > > keep track of all injected page requests. This is always my question when we start embedding IDs in structures. > > > > From SMMUv3 POV, it seems safe (haven't looked at SMMUv2 but I'm not > > so confident). > > > > * The guest can only send page responses to devices assigned to it, > > that's a given. > > > 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, Alex