virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Nicolin Chen <nicolinc@nvidia.com>,
	"Liu, Yi L" <yi.l.liu@intel.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/6] IOMMUFD: Deliver IO page faults to user space
Date: Wed, 8 Nov 2023 13:39:24 -0400	[thread overview]
Message-ID: <20231108173924.GF4634@ziepe.ca> (raw)
In-Reply-To: <BN9PR11MB52764A460BEDD56A56290BA48CA8A@BN9PR11MB5276.namprd11.prod.outlook.com>

On Wed, Nov 08, 2023 at 08:53:00AM +0000, Tian, Kevin wrote:

> > There are many events related to object in guest memory or controlled
> > by the guest, eg C_BAD_CD and C_BAD_STE. These should be relayed or
> > the emulation is not working well.
> 
> so that's the category of unrecoverable faults?

I haven't looked exhaustively but I do have the impression that the
only recoverable fault is the 'page not present' one.

> btw I can understand C_BAD_CD given it's walked by the physical SMMU
> in nested configuration. But presumably STE is created by the smmu
> driver itself then why would there be an error to be relayed for
> guest STE?

If the guest programs a bad STE it should still generate a C_BAD_STE
even if the mediation SW could theoretically sanitize it (but sanitize
it to what? BLOCKED?). Since we have to forward things like C_BAD_CD
and others we may as well just drop an invalid STE and forward the
event like real HW.

> > > but I didn't get the last piece. If those domains are created by kernel
> > > drivers why would they require a uAPI for userspace to specify fault
> > > capable?
> > 
> > Not to userspace, but a kapi to request a fault capable domain and to
> > supply the fault handler. Eg:
> > 
> >  iommu_domain_alloc_faultable(dev, handler);
> 
> Does it affect SVA too?

Inside the driver the SVA should be constructed out of the same fault
handling infrastructure, but a SVA domain allocation should have a
different allocation function.

Jason

  reply	other threads:[~2023-11-08 17:39 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20231026024930.382898-1-baolu.lu@linux.intel.com>
2023-11-02 12:47 ` [PATCH v2 0/6] IOMMUFD: Deliver IO page faults to user space Jason Gunthorpe
2023-11-07  8:35   ` Tian, Kevin
2023-11-07 17:54     ` Jason Gunthorpe
2023-11-08  8:53       ` Tian, Kevin
2023-11-08 17:39         ` Jason Gunthorpe [this message]
     [not found]   ` <c774e157-9b47-4fb8-80dd-37441c69b43d@linux.intel.com>
2023-11-15 13:58     ` Jason Gunthorpe
2023-11-16  1:42       ` Liu, Jing2
2023-11-21  0:14         ` Jason Gunthorpe
2023-11-29  9:08 ` Shameerali Kolothum Thodi
2023-11-30  3:44   ` Baolu Lu
2023-12-01 14:24 ` Jason Gunthorpe
2023-12-08  5:57   ` Baolu Lu
2023-12-08 13:43     ` Jason Gunthorpe
     [not found] ` <20231026024930.382898-2-baolu.lu@linux.intel.com>
2023-12-01 14:38   ` [PATCH v2 1/6] iommu: Add iommu page fault cookie helpers Jason Gunthorpe
2023-12-08  6:24     ` Baolu Lu
     [not found] ` <20231026024930.382898-3-baolu.lu@linux.intel.com>
2023-12-01 15:14   ` [PATCH v2 2/6] iommufd: Add iommu page fault uapi data Jason Gunthorpe
2023-12-08  6:35     ` Baolu Lu
     [not found] ` <20231026024930.382898-5-baolu.lu@linux.intel.com>
2023-12-01 15:24   ` [PATCH v2 4/6] iommufd: Deliver fault messages to user space Jason Gunthorpe
2023-12-08 11:43     ` Baolu Lu
     [not found]   ` <CGME20231207163412eucas1p2fa912b4923031804c27c764e5c8d67e7@eucas1p2.samsung.com>
2023-12-07 16:34     ` Joel Granados
2023-12-07 17:17       ` Jason Gunthorpe
2023-12-08  5:47         ` Baolu Lu
2023-12-08 13:41           ` Jason Gunthorpe
     [not found]   ` <b822096cc3b441309d99832c587be25a@huawei.com>
2024-01-15 16:47     ` Jason Gunthorpe
     [not found]       ` <b1663110e1ca4301834f403270357bea@huawei.com>
2024-01-15 17:58         ` Jason Gunthorpe
     [not found] ` <CGME20231204150747eucas1p2365e92a7ac33ba99b801d7c800acaf6a@eucas1p2.samsung.com>
2023-12-04 15:07   ` [PATCH v2 0/6] IOMMUFD: Deliver IO page faults " Joel Granados
2023-12-04 15:32     ` Jason Gunthorpe
2023-12-08  5:10     ` Baolu Lu
     [not found] ` <20231026024930.382898-4-baolu.lu@linux.intel.com>
     [not found]   ` <CGME20231212131010eucas1p104d069ac6d6c97fce4987caa62c996ee@eucas1p1.samsung.com>
2023-12-12 13:10     ` [PATCH v2 3/6] iommufd: Initializing and releasing IO page fault data Joel Granados
2023-12-12 14:12       ` Jason Gunthorpe
2023-12-13  2:04         ` Baolu Lu
2023-12-13  2:15           ` Tian, Kevin
2023-12-13 13:19             ` Jason Gunthorpe
     [not found] ` <CGME20240112215609eucas1p1eedeeee8e1cca2c935b41816a50f56f6@eucas1p1.samsung.com>
2024-01-12 21:56   ` [PATCH v2 0/6] IOMMUFD: Deliver IO page faults to user space Joel Granados
2024-01-14 13:13     ` Baolu Lu
2024-01-14 17:18       ` Joel Granados
2024-01-15  1:25         ` Baolu Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231108173924.GF4634@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).