From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "Raj, Ashok" <ashok.raj@intel.com>,
Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"robin.murphy@arm.com" <robin.murphy@arm.com>
Subject: Re: [PATCH v2 2/4] iommu: Introduce device fault data
Date: Wed, 5 Jun 2019 10:37:54 -0700 [thread overview]
Message-ID: <20190605103754.6d8830d7@jacob-builder> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D19CA6A9EE@SHSMSX104.ccr.corp.intel.com>
On Wed, 5 Jun 2019 08:51:45 +0000
"Tian, Kevin" <kevin.tian@intel.com> wrote:
> > From: Jacob Pan
> > Sent: Tuesday, June 4, 2019 6:09 AM
> >
> > On Mon, 3 Jun 2019 15:57:47 +0100
> > Jean-Philippe Brucker <jean-philippe.brucker@arm.com> wrote:
> >
> > > +/**
> > > + * struct iommu_fault_page_request - Page Request data
> > > + * @flags: encodes whether the corresponding fields are valid and
> > > whether this
> > > + * is the last page in group (IOMMU_FAULT_PAGE_REQUEST_*
> > > values)
> > > + * @pasid: Process Address Space ID
> > > + * @grpid: Page Request Group Index
> > > + * @perm: requested page permissions (IOMMU_FAULT_PERM_* values)
> > > + * @addr: page address
> > > + * @private_data: device-specific private information
> > > + */
> > > +struct iommu_fault_page_request {
> > > +#define IOMMU_FAULT_PAGE_REQUEST_PASID_VALID (1 << 0)
> > > +#define IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE (1 << 1)
> > > +#define IOMMU_FAULT_PAGE_REQUEST_PRIV_DATA (1 << 2)
> > > + __u32 flags;
> > > + __u32 pasid;
> > > + __u32 grpid;
> > > + __u32 perm;
> > > + __u64 addr;
> > > + __u64 private_data[2];
> > > +};
> > > +
> >
> > Just a thought, for non-identity G-H PASID management. We could
> > pass on guest PASID in PRQ to save a lookup in QEMU. In this case,
> > QEMU allocate a GPASID for vIOMMU then a host PASID for pIOMMU.
> > QEMU has a G->H lookup. When PRQ comes in to the pIOMMU with
> > HPASID, IOMMU driver
> > can retrieve GPASID from the bind data then report to the guest via
> > VFIO. In this case QEMU does not need to do a H->G PASID lookup.
> >
> > Should we add a gpasid field here? or we can add a flag and field
> > later, up to you.
> >
>
> Can private_data serve this purpose? It's better not introducing
> gpasid awareness within host IOMMU driver. It is just a user-level
> data associated with a PASID when binding happens. Kernel doesn't
> care the actual meaning, simply record it and then return back to
> user space later upon device fault. Qemu interprets the meaning as
> gpasid in its own context. otherwise usages may use it for other
> purpose.
>
private_data was intended for device PRQ with private data, part of the
VT-d PRQ descriptor. For vSVA, we can withhold private_data in the host
then respond back when page response from the guest matches pending PRQ
with the data withheld. But for in-kernel PRQ reporting, private data
still might be passed on to any driver who wants to process the PRQ. So
we can't re-purpose it.
But for in-kernel VDCM driver, it needs a lookup from guest PASID to
host PASID. I thought you wanted to have IOMMU driver provide such
service since the knowledge of H-G pasid can be established during
bind_gpasid time. In that sense, we _do_ have gpasid awareness.
> Thanks
> Kevin
[Jacob Pan]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-06-05 17:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-03 14:57 [PATCH v2 0/4] iommu: Add device fault reporting API Jean-Philippe Brucker
2019-06-03 14:57 ` [PATCH v2 1/4] driver core: Add per device iommu param Jean-Philippe Brucker
2019-06-03 14:57 ` [PATCH v2 2/4] iommu: Introduce device fault data Jean-Philippe Brucker
2019-06-03 22:08 ` Jacob Pan
2019-06-05 8:51 ` Tian, Kevin
2019-06-05 11:24 ` Jean-Philippe Brucker
2019-06-05 21:58 ` Jacob Pan
2019-06-05 17:37 ` Jacob Pan [this message]
2019-06-06 6:54 ` Tian, Kevin
2019-06-03 14:57 ` [PATCH v2 3/4] iommu: Introduce device fault report API Jean-Philippe Brucker
2019-06-03 14:57 ` [PATCH v2 4/4] iommu: Add recoverable fault reporting Jean-Philippe Brucker
2019-06-03 21:59 ` [PATCH v2 0/4] iommu: Add device fault reporting API Jacob Pan
2019-06-05 11:26 ` Jean-Philippe Brucker
2019-06-12 8:19 ` Joerg Roedel
2019-06-12 11:54 ` Jean-Philippe Brucker
2019-06-12 13:11 ` Joerg Roedel
2019-06-12 17:59 ` [PATCH] iommu: Add padding to struct iommu_fault Jean-Philippe Brucker
2019-06-12 19:02 ` Jacob Pan
2019-06-12 19:19 ` Auger Eric
2019-06-18 15:15 ` Joerg Roedel
2019-06-12 18:58 ` [PATCH v2 0/4] iommu: Add device fault reporting API Jacob Pan
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=20190605103754.6d8830d7@jacob-builder \
--to=jacob.jun.pan@linux.intel.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe.brucker@arm.com \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.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).