linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Alex Williamson <alex.williamson@redhat.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: "iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Joerg Roedel <joro@8bytes.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	David Woodhouse <dwmw2@infradead.org>,
	"Liu, Yi L" <yi.l.liu@intel.com>,
	"Raj, Ashok" <ashok.raj@intel.com>,
	"Christoph Hellwig" <hch@infradead.org>,
	Jean-Philippe Brucker <jean-philippe@linaro.com>,
	Eric Auger <eric.auger@redhat.com>,
	"Jonathan Corbet" <corbet@lwn.net>
Subject: RE: [PATCH v6 1/6] docs: IOMMU user API
Date: Wed, 29 Jul 2020 01:18:04 +0000	[thread overview]
Message-ID: <MWHPR11MB1645BA0C8436C3280DBDC5468C700@MWHPR11MB1645.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20200728131950.2aff140d@x1.home>

> From: Alex Williamson <alex.williamson@redhat.com>
> Sent: Wednesday, July 29, 2020 3:20 AM
> 
[...]
> > +
> > +For example, IOTLB invalidations should always succeed. There is no
> > +architectural way to report back to the vIOMMU if the UAPI data is
> > +incompatible. If that happens, in order to guarantee IOMMU iosolation,
> 
> isolation
> 
> > +we have to resort to not giving completion status in vIOMMU. This may
> > +result in VM hang.
> > +
> > +For this reason the following IOMMU UAPIs cannot fail without
> > +catastrophic effect:
> > +
> > +1. Free PASID
> > +2. Unbind guest PASID
> > +3. Unbind guest PASID table (SMMU)
> > +4. Cache invalidate
> 
> I'm not entirely sure what we're trying to assert here.  Clearly cache
> invalidation can fail and patch 5/6 goes on to add over a dozen checks
> of the user provided data that return an -errno.  Any user ioctl can
> fail if the user botches the parameters.  So are we just trying to
> explain the feature checking that should allow the user to know
> supported combinations and if they adhere to them, these should not
> fail?  It's not quite worded to that effect.  Thanks,
> 

I guess the above wording is messed by what a UAPI should
behave and whether the vIOMMU reports associated errors.
UAPI can always fail, as you pointed out. vIOMMU may not
have a matching error code though, e.g. on Intel VT-d there is no
error reporting mechanism for cache invalidation. However,
it is not wise to assert UAPI behavior according to vIOMMU
definition. An error is an error. vIOMMU should just react to
UAPI errors according to its architecture definition (e.g. ignore,
forward to guest, hang, etc.). From this matter I feel above
section could better be removed.

Thanks
Kevin

  reply	other threads:[~2020-07-29  1:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-23 17:25 [PATCH v6 0/6] IOMMU user API enhancement Jacob Pan
2020-07-23 17:25 ` [PATCH v6 1/6] docs: IOMMU user API Jacob Pan
2020-07-28 19:19   ` Alex Williamson
2020-07-29  1:18     ` Tian, Kevin [this message]
2020-07-29 21:02       ` Jacob Pan
2020-07-23 17:25 ` [PATCH v6 2/6] iommu/uapi: Add argsz for user filled data Jacob Pan
2020-07-23 17:25 ` [PATCH v6 3/6] iommu/uapi: Use named union for user data Jacob Pan
2020-07-23 17:25 ` [PATCH v6 4/6] iommu/uapi: Rename uapi functions Jacob Pan
2020-07-23 17:25 ` [PATCH v6 5/6] iommu/uapi: Handle data and argsz filled by users Jacob Pan
2020-07-28 19:19   ` Alex Williamson
2020-07-29 22:05     ` Jacob Pan
2020-07-23 17:25 ` [PATCH v6 6/6] iommu/vt-d: Check UAPI data processed by IOMMU core 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=MWHPR11MB1645BA0C8436C3280DBDC5468C700@MWHPR11MB1645.namprd11.prod.outlook.com \
    --to=kevin.tian@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=dwmw2@infradead.org \
    --cc=eric.auger@redhat.com \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jean-philippe@linaro.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.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).