All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: iommu@lists.linux-foundation.org,
	Alex Williamson <alex.williamson@redhat.com>,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Subject: Re: [PATCH 2/2] iommu/vt-d: Fix unmap_pages support
Date: Fri, 26 Nov 2021 20:47:05 +0800	[thread overview]
Message-ID: <79b1fe69-9672-6cb7-88b1-f4eaffa7add9@linux.intel.com> (raw)
In-Reply-To: <20211122032458.2549761-3-baolu.lu@linux.intel.com>

On 2021/11/22 11:24, Lu Baolu wrote:
> From: Alex Williamson<alex.williamson@redhat.com>
> 
> When supporting only the .map and .unmap callbacks of iommu_ops,
> the IOMMU driver can make assumptions about the size and alignment
> used for mappings based on the driver provided pgsize_bitmap.  VT-d
> previously used essentially PAGE_MASK for this bitmap as any power
> of two mapping was acceptably filled by native page sizes.
> 
> However, with the .map_pages and .unmap_pages interface we're now
> getting page-size and count arguments.  If we simply combine these
> as (page-size * count) and make use of the previous map/unmap
> functions internally, any size and alignment assumptions are very
> different.
> 
> As an example, a given vfio device assignment VM will often create
> a 4MB mapping at IOVA pfn [0x3fe00 - 0x401ff].  On a system that
> does not support IOMMU super pages, the unmap_pages interface will
> ask to unmap 1024 4KB pages at the base IOVA.  dma_pte_clear_level()
> will recurse down to level 2 of the page table where the first half
> of the pfn range exactly matches the entire pte level.  We clear the
> pte, increment the pfn by the level size, but (oops) the next pte is
> on a new page, so we exit the loop an pop back up a level.  When we
> then update the pfn based on that higher level, we seem to assume
> that the previous pfn value was at the start of the level.  In this
> case the level size is 256K pfns, which we add to the base pfn and
> get a results of 0x7fe00, which is clearly greater than 0x401ff,
> so we're done.  Meanwhile we never cleared the ptes for the remainder
> of the range.  When the VM remaps this range, we're overwriting valid
> ptes and the VT-d driver complains loudly, as reported by the user
> report linked below.
> 
> The fix for this seems relatively simple, if each iteration of the
> loop in dma_pte_clear_level() is assumed to clear to the end of the
> level pte page, then our next pfn should be calculated from level_pfn
> rather than our working pfn.
> 
> Fixes: 3f34f1259776 ("iommu/vt-d: Implement map/unmap_pages() iommu_ops callback")
> Reported-by: Ajay Garg<ajaygargnsit@gmail.com>
> Signed-off-by: Alex Williamson<alex.williamson@redhat.com>
> Tested-by: Giovanni Cabiddu<giovanni.cabiddu@intel.com>
> Link:https://lore.kernel.org/all/20211002124012.18186-1-ajaygargnsit@gmail.com/
> Link:https://lore.kernel.org/r/163659074748.1617923.12716161410774184024.stgit@omen
> Signed-off-by: Lu Baolu<baolu.lu@linux.intel.com>

0-day build robot reported an error on this patch.

"drivers/iommu/intel/iommu.c:1344:7: warning: variable 'level_pfn' is 
used uninitialized whenever 'if' condition is true 
[-Wsometimes-uninitialized]
"

I will send a v2 of this patch. Sorry for the inconvenience.

Best regards
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2021-11-26 12:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-22  3:24 [PATCH 0/2] iommu/vt-d: Fixes for v5.16-rc3 Lu Baolu
2021-11-22  3:24 ` [PATCH 1/2] iommu/vt-d: Fix an unbalanced rcu_read_lock/rcu_read_unlock() Lu Baolu
2021-11-22  3:24 ` [PATCH 2/2] iommu/vt-d: Fix unmap_pages support Lu Baolu
2021-11-26 12:47   ` Lu Baolu [this message]
2021-11-23 11:15 ` [PATCH 0/2] iommu/vt-d: Fixes for v5.16-rc3 Joerg Roedel

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=79b1fe69-9672-6cb7-88b1-f4eaffa7add9@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.