iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Auger Eric <eric.auger@redhat.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	Raj Ashok <ashok.raj@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	iommu@lists.linux-foundation.org,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v3 6/7] iommu/vt-d: Warn on out-of-range invalidation address
Date: Thu, 2 Jul 2020 06:43:41 -0700	[thread overview]
Message-ID: <20200702064341.18d513a5@jacob-builder> (raw)
In-Reply-To: <7c265689-a23c-021b-27e7-beb3cd667a5f@redhat.com>

Hi Eric,

On Thu, 2 Jul 2020 10:47:39 +0200
Auger Eric <eric.auger@redhat.com> wrote:

> Hi,
> 
> On 7/1/20 5:33 PM, Jacob Pan wrote:
> > For guest requested IOTLB invalidation, address and mask are
> > provided as part of the invalidation data. VT-d HW silently ignores
> > any address bits below the mask. SW shall also allow such case but
> > give warning if address does not align with the mask. This patch
> > relax the fault handling from error to warning and proceed with
> > invalidation request with the given mask.  
> What I don't really get is the guest shouldn't do that. Don't we want
> to be more strict in that case and return an error?
> 
My thinking is that the driver should behave the same level of leniency
as the HW. The other concern is that the consequence is severe, if TLB
invalidation failed, we have hang the guest to protect security.

> Thanks
> 
> Eric
> > 
> > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> > ---
> >  drivers/iommu/intel/iommu.c | 7 +++----
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/iommu/intel/iommu.c
> > b/drivers/iommu/intel/iommu.c index 6a0c62c7395c..2e1b53ade784
> > 100644 --- a/drivers/iommu/intel/iommu.c
> > +++ b/drivers/iommu/intel/iommu.c
> > @@ -5439,13 +5439,12 @@ intel_iommu_sva_invalidate(struct
> > iommu_domain *domain, struct device *dev, 
> >  		switch (BIT(cache_type)) {
> >  		case IOMMU_CACHE_INV_TYPE_IOTLB:
> > +			/* HW will ignore LSB bits based on
> > address mask */ if (inv_info->granularity == IOMMU_INV_GRANU_ADDR &&
> >  			    size &&
> >  			    (inv_info->addr_info.addr &
> > ((BIT(VTD_PAGE_SHIFT + size)) - 1))) {
> > -				pr_err_ratelimited("Address out of
> > range, 0x%llx, size order %llu\n",
> > -
> > inv_info->addr_info.addr, size);
> > -				ret = -ERANGE;
> > -				goto out_unlock;
> > +				pr_err_ratelimited("User address
> > not aligned, 0x%llx, size order %llu\n",
> > +
> > inv_info->addr_info.addr, size); }
> >  
> >  			/*
> >   
> 

[Jacob Pan]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2020-07-02 13:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-01 15:33 [PATCH v3 0/7] iommu/vt-d: Misc tweaks and fixes for vSVA Jacob Pan
2020-07-01 15:33 ` [PATCH v3 1/7] iommu/vt-d: Enforce PASID devTLB field mask Jacob Pan
2020-07-02  7:16   ` Auger Eric
2020-07-01 15:33 ` [PATCH v3 2/7] iommu/vt-d: Remove global page support in devTLB flush Jacob Pan
2020-07-02  7:16   ` Auger Eric
2020-07-06 23:58     ` Jacob Pan
2020-07-01 15:33 ` [PATCH v3 3/7] iommu/vt-d: Fix PASID devTLB invalidation Jacob Pan
2020-07-02  0:50   ` Lu Baolu
2020-07-02  7:16   ` Auger Eric
2020-07-01 15:33 ` [PATCH v3 4/7] iommu/vt-d: Handle non-page aligned address Jacob Pan
2020-07-02  7:50   ` Auger Eric
2020-07-06 23:28     ` Jacob Pan
2020-07-01 15:33 ` [PATCH v3 5/7] iommu/vt-d: Fix devTLB flush for vSVA Jacob Pan
2020-07-02  8:39   ` Auger Eric
2020-07-06 21:05     ` Jacob Pan
2020-07-01 15:33 ` [PATCH v3 6/7] iommu/vt-d: Warn on out-of-range invalidation address Jacob Pan
2020-07-02  0:55   ` Lu Baolu
2020-07-02  8:47   ` Auger Eric
2020-07-02 13:43     ` Jacob Pan [this message]
2020-07-01 15:33 ` [PATCH v3 7/7] iommu/vt-d: Disable multiple GPASID-dev bind Jacob Pan
2020-07-02  8:50   ` Auger Eric

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=20200702064341.18d513a5@jacob-builder \
    --to=jacob.jun.pan@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    /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).