Linux IOMMU Development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox