linux-kernel - Re: [PATCH v3 15/16] iommu: introduce page response function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171204133715.50c45136@jacob-builder>
Date:   Mon, 4 Dec 2017 13:37:15 -0800
From:   Jacob Pan <jacob.jun.pan@...ux.intel.com>
To:     Jean-Philippe Brucker <jean-philippe.brucker@....com>
Cc:     "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>,
        Alex Williamson <alex.williamson@...hat.com>,
        Lan Tianyu <tianyu.lan@...el.com>,
        Jean Delvare <khali@...ux-fr.org>,
        jacob.jun.pan@...ux.intel.com
Subject: Re: [PATCH v3 15/16] iommu: introduce page response function

On Fri, 24 Nov 2017 12:03:50 +0000
Jean-Philippe Brucker <jean-philippe.brucker@....com> 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 <jacob.jun.pan@...ux.intel.com>
> > ---
> >  drivers/iommu/iommu.c | 14 ++++++++++++++
> >  include/linux/iommu.h | 42
> > ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 56
> > insertions(+)
> > 
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index 97b7990..7aefb40 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -1416,6 +1416,20 @@ int iommu_sva_invalidate(struct iommu_domain
> > *domain, }
> >  EXPORT_SYMBOL_GPL(iommu_sva_invalidate);
> >  
> > +int iommu_page_response(struct iommu_domain *domain, struct device
> > *dev,
> > +			struct page_response_msg *msg)  
> 
> I think it's simpler, both for IOMMU and device drivers, to pass the
> exact structure received in the fault handler back to the IOMMU
> driver, along with a separate response status. So maybe
> 
> int iommu_page_response(struct iommu_domain *domain, struct device
> *dev, struct iommu_fault_event *event, u32 response)
> 
> And then you'd just need to define the IOMMU_PAGE_RESPONSE_* values.
> 
Apologize for the late response,

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.
> Thanks,
> Jean

[Jacob Pan]