All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: jiangyiwen <jiangyiwen@huawei.com>
Cc: <kvm@vger.kernel.org>
Subject: Re: [bug report] vfio: Can't find phys by iova in vfio_unmap_unpin()
Date: Mon, 20 May 2019 13:28:01 -0600	[thread overview]
Message-ID: <20190520132801.4e2ab8ab@x1.home> (raw)
In-Reply-To: <5CE25C33.2060009@huawei.com>

On Mon, 20 May 2019 15:50:11 +0800
jiangyiwen <jiangyiwen@huawei.com> wrote:

> Hello alex,
> 
> We test a call trace as follows use ARM64 architecture,
> it prints a WARN_ON() when find not physical address by
> iova in vfio_unmap_unpin(), I can't find the cause of
> problem now, do you have any ideas?

Is it reproducible?  Can you explain how to reproduce it?  The stack
trace indicates a KVM VM is being shutdown and we're trying to clean
out the IOMMU mappings from the domain and find a page that we think
should be mapped that the IOMMU doesn't have mapped.  What device(s) was
assigned to the VM?  This could be an IOMMU driver bug or a
vfio_iommu_type1 bug.  Have you been able to reproduce this on other
platforms?

> In addition, I want to know why there is a WARN_ON() instead
> of BUG_ON()? Does it affect the follow-up process?

We're removing an IOMMU page mapping entry and find that it's not
present, so ultimately the effect at the IOMMU is the same, there's no
mapping at that address, but I can't say without further analysis
whether that means a page remains pinned or if that inconsistency was
resolved previously elsewhere.  We WARN_ON because this is not what we
expect, but potentially leaking a page of memory doesn't seem worthy of
crashing the host, nor would a crash dump at that point necessarily aid
in resolving the missing page as it potentially occurred well in the
past.  Thanks,

Alex

  reply	other threads:[~2019-05-20 19:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-20  7:50 [bug report] vfio: Can't find phys by iova in vfio_unmap_unpin() jiangyiwen
2019-05-20 19:28 ` Alex Williamson [this message]
2019-06-11  3:21   ` jiangyiwen
     [not found]     ` <5CFFA149.8070303@huawei.com>
2019-06-11 15:13       ` Alex Williamson
2019-06-11 15:13         ` Alex Williamson

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=20190520132801.4e2ab8ab@x1.home \
    --to=alex.williamson@redhat.com \
    --cc=jiangyiwen@huawei.com \
    --cc=kvm@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 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.