From: jiangyiwen <jiangyiwen@huawei.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: <kvm@vger.kernel.org>
Subject: Re: [bug report] vfio: Can't find phys by iova in vfio_unmap_unpin()
Date: Tue, 11 Jun 2019 11:21:25 +0800 [thread overview]
Message-ID: <5CFF1E35.5010602@huawei.com> (raw)
In-Reply-To: <20190520132801.4e2ab8ab@x1.home>
On 2019/5/21 3:28, Alex Williamson wrote:
> 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?
>
Hello Alex,
Sorry to reply you so late because of some things,
this problem's reason is in some platform (like ARM64),
the "0" physical address is valid and can be used for
system memory, so in this case it should not print a
WARN_ON() and continue, we should unmap and unpin this
"0" physical address in these platform.
So I want to return FFFFFFFFFFFFFFFFL instead of "0" as invalid
physical address in function iommu_iova_to_phys(). Do you think
it's appropriate?
Thanks,
Yiwen.
>> 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
>
> .
>
next prev parent reply other threads:[~2019-06-11 3:21 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
2019-06-11 3:21 ` jiangyiwen [this message]
[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=5CFF1E35.5010602@huawei.com \
--to=jiangyiwen@huawei.com \
--cc=alex.williamson@redhat.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.