From: Xunlei Pang <xpang@redhat.com>
To: Joerg Roedel <joro@8bytes.org>, xlpang@redhat.com
Cc: Don Brace <don.brace@microsemi.com>,
Myron Stowe <myron.stowe@redhat.com>,
kexec@lists.infradead.org, LKML <linux-kernel@vger.kernel.org>,
iommu@lists.linux-foundation.org,
Myron Stowe <myron.stowe@gmail.com>,
Dave Young <dyoung@redhat.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH] iommu/vt-d: Flush old iotlb for kdump when the device gets context mapped
Date: Wed, 30 Nov 2016 16:15:23 +0800 [thread overview]
Message-ID: <583E8A9B.7070906@redhat.com> (raw)
In-Reply-To: <20161129143547.GG2078@8bytes.org>
On 11/29/2016 at 10:35 PM, Joerg Roedel wrote:
> On Thu, Nov 17, 2016 at 10:47:28AM +0800, Xunlei Pang wrote:
>> As per the comment, the code here only needs to flush context caches
>> for the special domain 0 which is used to tag the
>> non-present/erroneous caches, seems we should flush the old domain id
>> of present entries for kdump according to the analysis, other than the
>> new-allocated domain id. Let me ponder more on this.
> Flushing the context entry only is fine. The old domain-id will not be
> re-used anyway, so there is no point in reading it out of the context
> table and flush it.
Do you mean to flush the context entry using the new-allocated domain id?
Yes, old domain-id will not be re-used as they were reserved when copy, but
may still be cached by in-flight DMA access.
Here is what the things seem to be from my understanding, and why I want to
flush using the old domain id:
1) In kdump mode, old tables are copied, and all the iommu caches are flushed.
2) There comes some in-flight DMA before the device's new context is mapped,
so translation caches(context, iotlb, etc) are created tagging old domain-id
in the iommu hardware.
3) At the driver probe stage, the device is reset , and no in-flight DMA will exist.
Here I assumed that the device reset won't flush the old caches in the iommu
hardware related to this device. I haven't found any relevant specification, please
correct me if I am wrong.
4) Then new context is setup, and new DMA is initiated, hit old cache that was
created in 2) as currently there's no such flush action, so DMAR fault happens.
I already posted v2 to flush context/iotlb using the old domain-id:
https://lkml.org/lkml/2016/11/18/514
Regards,
Xunlei
>
> Also, please add a Fixes-tag when you re-post this patch.
>
>
> Joerg
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Xunlei Pang <xpang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>,
xlpang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Cc: Don Brace <don.brace-dzo6w/eZyo2tG0bUXCXiUA@public.gmane.org>,
Myron Stowe <myron.stowe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Subject: Re: [PATCH] iommu/vt-d: Flush old iotlb for kdump when the device gets context mapped
Date: Wed, 30 Nov 2016 16:15:23 +0800 [thread overview]
Message-ID: <583E8A9B.7070906@redhat.com> (raw)
In-Reply-To: <20161129143547.GG2078-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
On 11/29/2016 at 10:35 PM, Joerg Roedel wrote:
> On Thu, Nov 17, 2016 at 10:47:28AM +0800, Xunlei Pang wrote:
>> As per the comment, the code here only needs to flush context caches
>> for the special domain 0 which is used to tag the
>> non-present/erroneous caches, seems we should flush the old domain id
>> of present entries for kdump according to the analysis, other than the
>> new-allocated domain id. Let me ponder more on this.
> Flushing the context entry only is fine. The old domain-id will not be
> re-used anyway, so there is no point in reading it out of the context
> table and flush it.
Do you mean to flush the context entry using the new-allocated domain id?
Yes, old domain-id will not be re-used as they were reserved when copy, but
may still be cached by in-flight DMA access.
Here is what the things seem to be from my understanding, and why I want to
flush using the old domain id:
1) In kdump mode, old tables are copied, and all the iommu caches are flushed.
2) There comes some in-flight DMA before the device's new context is mapped,
so translation caches(context, iotlb, etc) are created tagging old domain-id
in the iommu hardware.
3) At the driver probe stage, the device is reset , and no in-flight DMA will exist.
Here I assumed that the device reset won't flush the old caches in the iommu
hardware related to this device. I haven't found any relevant specification, please
correct me if I am wrong.
4) Then new context is setup, and new DMA is initiated, hit old cache that was
created in 2) as currently there's no such flush action, so DMAR fault happens.
I already posted v2 to flush context/iotlb using the old domain-id:
https://lkml.org/lkml/2016/11/18/514
Regards,
Xunlei
>
> Also, please add a Fixes-tag when you re-post this patch.
>
>
> Joerg
>
WARNING: multiple messages have this Message-ID (diff)
From: Xunlei Pang <xpang@redhat.com>
To: Joerg Roedel <joro@8bytes.org>, xlpang@redhat.com
Cc: Myron Stowe <myron.stowe@gmail.com>,
iommu@lists.linux-foundation.org,
Don Brace <don.brace@microsemi.com>,
Dave Young <dyoung@redhat.com>,
kexec@lists.infradead.org, LKML <linux-kernel@vger.kernel.org>,
Myron Stowe <myron.stowe@redhat.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH] iommu/vt-d: Flush old iotlb for kdump when the device gets context mapped
Date: Wed, 30 Nov 2016 16:15:23 +0800 [thread overview]
Message-ID: <583E8A9B.7070906@redhat.com> (raw)
In-Reply-To: <20161129143547.GG2078@8bytes.org>
On 11/29/2016 at 10:35 PM, Joerg Roedel wrote:
> On Thu, Nov 17, 2016 at 10:47:28AM +0800, Xunlei Pang wrote:
>> As per the comment, the code here only needs to flush context caches
>> for the special domain 0 which is used to tag the
>> non-present/erroneous caches, seems we should flush the old domain id
>> of present entries for kdump according to the analysis, other than the
>> new-allocated domain id. Let me ponder more on this.
> Flushing the context entry only is fine. The old domain-id will not be
> re-used anyway, so there is no point in reading it out of the context
> table and flush it.
Do you mean to flush the context entry using the new-allocated domain id?
Yes, old domain-id will not be re-used as they were reserved when copy, but
may still be cached by in-flight DMA access.
Here is what the things seem to be from my understanding, and why I want to
flush using the old domain id:
1) In kdump mode, old tables are copied, and all the iommu caches are flushed.
2) There comes some in-flight DMA before the device's new context is mapped,
so translation caches(context, iotlb, etc) are created tagging old domain-id
in the iommu hardware.
3) At the driver probe stage, the device is reset , and no in-flight DMA will exist.
Here I assumed that the device reset won't flush the old caches in the iommu
hardware related to this device. I haven't found any relevant specification, please
correct me if I am wrong.
4) Then new context is setup, and new DMA is initiated, hit old cache that was
created in 2) as currently there's no such flush action, so DMAR fault happens.
I already posted v2 to flush context/iotlb using the old domain-id:
https://lkml.org/lkml/2016/11/18/514
Regards,
Xunlei
>
> Also, please add a Fixes-tag when you re-post this patch.
>
>
> Joerg
>
next prev parent reply other threads:[~2016-11-30 8:14 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-16 9:02 [PATCH] iommu/vt-d: Flush old iotlb for kdump when the device gets context mapped Xunlei Pang
2016-11-16 9:02 ` Xunlei Pang
2016-11-16 9:02 ` Xunlei Pang
2016-11-16 9:13 ` Xunlei Pang
2016-11-16 9:13 ` Xunlei Pang
2016-11-16 9:13 ` Xunlei Pang
2016-11-16 14:58 ` Myron Stowe
2016-11-16 14:58 ` Myron Stowe
2016-11-16 14:58 ` Myron Stowe
2016-11-17 2:47 ` Xunlei Pang
2016-11-17 2:47 ` Xunlei Pang
2016-11-17 2:47 ` Xunlei Pang
[not found] ` <582D1A40.409-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-11-29 14:35 ` Joerg Roedel
2016-11-29 14:35 ` Joerg Roedel
2016-11-30 8:15 ` Xunlei Pang [this message]
2016-11-30 8:15 ` Xunlei Pang
2016-11-30 8:15 ` Xunlei Pang
2016-11-30 9:03 ` Baoquan He
2016-11-30 9:03 ` Baoquan He
2016-11-30 9:03 ` Baoquan He
2016-11-30 9:53 ` Baoquan He
2016-11-30 9:53 ` Baoquan He
2016-11-30 9:53 ` Baoquan He
2016-11-30 10:23 ` Baoquan He
2016-11-30 10:23 ` Baoquan He
2016-11-30 10:23 ` Baoquan He
2016-11-30 14:26 ` Joerg Roedel
2016-11-30 14:26 ` Joerg Roedel
2016-12-01 2:15 ` Xunlei Pang
2016-12-01 2:15 ` Xunlei Pang
2016-12-01 2:15 ` Xunlei Pang
[not found] ` <583F87D1.6030402-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-12-01 10:33 ` Joerg Roedel
2016-12-01 10:33 ` Joerg Roedel
2016-12-01 11:44 ` Xunlei Pang
2016-12-01 11:44 ` Xunlei Pang
2016-12-01 11:44 ` Xunlei Pang
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=583E8A9B.7070906@redhat.com \
--to=xpang@redhat.com \
--cc=don.brace@microsemi.com \
--cc=dwmw2@infradead.org \
--cc=dyoung@redhat.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=myron.stowe@gmail.com \
--cc=myron.stowe@redhat.com \
--cc=xlpang@redhat.com \
/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.