From: "Li, ZhenHua" <zhen-hual@hp.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: dwmw2@infradead.org, indou.takao@jp.fujitsu.com, bhe@redhat.com,
vgoyal@redhat.com, dyoung@redhat.com,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, kexec@lists.infradead.org,
alex.williamson@redhat.com, ddutile@redhat.com,
ishii.hironobu@jp.fujitsu.com, bhelgaas@google.com,
doug.hatch@hp.com, jerry.hoemann@hp.com, tom.vaden@hp.com,
li.zhang6@hp.com, lisa.mitchell@hp.com,
billsumnerlinux@gmail.com, rwright@hp.com, "Li,
ZhenHua" <zhen-hual@hp.com>
Subject: Re: [PATCH v9 07/10] iommu/vt-d: enable kdump support in iommu module
Date: Fri, 03 Apr 2015 15:45:19 +0800 [thread overview]
Message-ID: <551E450F.4030903@hp.com> (raw)
In-Reply-To: <20150402110608.GL4441@8bytes.org>
Hi Joerg,
Thinking about it carefully, I think you suggestions are very helpful,
and the checks should be:
* All these things should be done in the second kernel, not only the
kdump kernel. Sometimes user may use kexec manually start a new kernel.
* Copying those tables should only happen in the second kernel, only in
this situation: iommu is enabled in both first and second kernel.
So, I think we can do this:
1. Use a new variable iommu_enabled_in_last_kernel;
2. When iommu module is loaded, it means the iommu is enabled in current
kernel. Then we check DMA_GSTS_TES:
* if DMA_GSTS_TES is set, then it should be the second kernel(kexec
starts this kernel manually, or it is kdump kernel), and the first
kernel used iommu tables. Here we need to copy these tables; then set
iommu_enabled_in_last_kernel to 1.
* if DMA_GSTS_TES is NOT set, then we do not need to care about
these tables.
3. Replace all
#ifdef CONFIG_CRASH_DUMP
if (is_kdump_kernel()) {
// Do some thing
}
#endif
To:
if (iommu_enabled_in_last_kernel) {
// Do some thing
}
Do you agree with these?
Thanks
Zhenhua
On 04/02/2015 07:06 PM, Joerg Roedel wrote:
> On Thu, Mar 19, 2015 at 01:36:25PM +0800, Li, Zhen-Hua wrote:
>> +#ifdef CONFIG_CRASH_DUMP
>> + if (is_kdump_kernel())
>> + __iommu_update_old_root_entry(iommu, bus);
>> +#endif
>
> All the is_kdump_kernel checks in this patch (and maybe in other patches
> too) should really be checks whether translation on the IOMMU was
> enabled or not when the kernel booted. You might also boot from a kernel
> that had translation disabled into a kdump kernel that wants to enable
> it. In this case these checks would break.
>
> Speaking of booting from kernels with translation disabled, there is a
> valid use of is_kdump_enabled(), to omit iommu initialization in the
> kdump kernel when translation was disabled before. But the other checks
> should depend on the state the iommu had when booting the kdump kernel.
>
>
> Joerg
>
WARNING: multiple messages have this Message-ID (diff)
From: "Li, ZhenHua" <zhen-hual-VXdhtT5mjnY@public.gmane.org>
To: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
Cc: bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
tom.vaden-VXdhtT5mjnY@public.gmane.org,
rwright-VXdhtT5mjnY@public.gmane.org,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
lisa.mitchell-VXdhtT5mjnY@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
"Li, ZhenHua" <zhen-hual-VXdhtT5mjnY@public.gmane.org>,
doug.hatch-VXdhtT5mjnY@public.gmane.org,
ishii.hironobu-+CUm20s59erQFUHtdCDX3A@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
billsumnerlinux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
li.zhang6-VXdhtT5mjnY@public.gmane.org,
dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH v9 07/10] iommu/vt-d: enable kdump support in iommu module
Date: Fri, 03 Apr 2015 15:45:19 +0800 [thread overview]
Message-ID: <551E450F.4030903@hp.com> (raw)
In-Reply-To: <20150402110608.GL4441-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
Hi Joerg,
Thinking about it carefully, I think you suggestions are very helpful,
and the checks should be:
* All these things should be done in the second kernel, not only the
kdump kernel. Sometimes user may use kexec manually start a new kernel.
* Copying those tables should only happen in the second kernel, only in
this situation: iommu is enabled in both first and second kernel.
So, I think we can do this:
1. Use a new variable iommu_enabled_in_last_kernel;
2. When iommu module is loaded, it means the iommu is enabled in current
kernel. Then we check DMA_GSTS_TES:
* if DMA_GSTS_TES is set, then it should be the second kernel(kexec
starts this kernel manually, or it is kdump kernel), and the first
kernel used iommu tables. Here we need to copy these tables; then set
iommu_enabled_in_last_kernel to 1.
* if DMA_GSTS_TES is NOT set, then we do not need to care about
these tables.
3. Replace all
#ifdef CONFIG_CRASH_DUMP
if (is_kdump_kernel()) {
// Do some thing
}
#endif
To:
if (iommu_enabled_in_last_kernel) {
// Do some thing
}
Do you agree with these?
Thanks
Zhenhua
On 04/02/2015 07:06 PM, Joerg Roedel wrote:
> On Thu, Mar 19, 2015 at 01:36:25PM +0800, Li, Zhen-Hua wrote:
>> +#ifdef CONFIG_CRASH_DUMP
>> + if (is_kdump_kernel())
>> + __iommu_update_old_root_entry(iommu, bus);
>> +#endif
>
> All the is_kdump_kernel checks in this patch (and maybe in other patches
> too) should really be checks whether translation on the IOMMU was
> enabled or not when the kernel booted. You might also boot from a kernel
> that had translation disabled into a kdump kernel that wants to enable
> it. In this case these checks would break.
>
> Speaking of booting from kernels with translation disabled, there is a
> valid use of is_kdump_enabled(), to omit iommu initialization in the
> kdump kernel when translation was disabled before. But the other checks
> should depend on the state the iommu had when booting the kdump kernel.
>
>
> Joerg
>
WARNING: multiple messages have this Message-ID (diff)
From: "Li, ZhenHua" <zhen-hual@hp.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: alex.williamson@redhat.com, indou.takao@jp.fujitsu.com,
bhe@redhat.com, tom.vaden@hp.com, rwright@hp.com,
dwmw2@infradead.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, lisa.mitchell@hp.com,
jerry.hoemann@hp.com, iommu@lists.linux-foundation.org, "Li,
ZhenHua" <zhen-hual@hp.com>,
ddutile@redhat.com, doug.hatch@hp.com,
ishii.hironobu@jp.fujitsu.com, linux-pci@vger.kernel.org,
bhelgaas@google.com, billsumnerlinux@gmail.com, li.zhang6@hp.com,
dyoung@redhat.com, vgoyal@redhat.com
Subject: Re: [PATCH v9 07/10] iommu/vt-d: enable kdump support in iommu module
Date: Fri, 03 Apr 2015 15:45:19 +0800 [thread overview]
Message-ID: <551E450F.4030903@hp.com> (raw)
In-Reply-To: <20150402110608.GL4441@8bytes.org>
Hi Joerg,
Thinking about it carefully, I think you suggestions are very helpful,
and the checks should be:
* All these things should be done in the second kernel, not only the
kdump kernel. Sometimes user may use kexec manually start a new kernel.
* Copying those tables should only happen in the second kernel, only in
this situation: iommu is enabled in both first and second kernel.
So, I think we can do this:
1. Use a new variable iommu_enabled_in_last_kernel;
2. When iommu module is loaded, it means the iommu is enabled in current
kernel. Then we check DMA_GSTS_TES:
* if DMA_GSTS_TES is set, then it should be the second kernel(kexec
starts this kernel manually, or it is kdump kernel), and the first
kernel used iommu tables. Here we need to copy these tables; then set
iommu_enabled_in_last_kernel to 1.
* if DMA_GSTS_TES is NOT set, then we do not need to care about
these tables.
3. Replace all
#ifdef CONFIG_CRASH_DUMP
if (is_kdump_kernel()) {
// Do some thing
}
#endif
To:
if (iommu_enabled_in_last_kernel) {
// Do some thing
}
Do you agree with these?
Thanks
Zhenhua
On 04/02/2015 07:06 PM, Joerg Roedel wrote:
> On Thu, Mar 19, 2015 at 01:36:25PM +0800, Li, Zhen-Hua wrote:
>> +#ifdef CONFIG_CRASH_DUMP
>> + if (is_kdump_kernel())
>> + __iommu_update_old_root_entry(iommu, bus);
>> +#endif
>
> All the is_kdump_kernel checks in this patch (and maybe in other patches
> too) should really be checks whether translation on the IOMMU was
> enabled or not when the kernel booted. You might also boot from a kernel
> that had translation disabled into a kdump kernel that wants to enable
> it. In this case these checks would break.
>
> Speaking of booting from kernels with translation disabled, there is a
> valid use of is_kdump_enabled(), to omit iommu initialization in the
> kdump kernel when translation was disabled before. But the other checks
> should depend on the state the iommu had when booting the kdump kernel.
>
>
> Joerg
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2015-04-03 7:46 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-19 5:36 [PATCH v9 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 01/10] iommu/vt-d: New function to attach domain with id Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 02/10] iommu/vt-d: Items required for kdump Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 03/10] iommu/vt-d: Function to get old context entry Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 04/10] iommu/vt-d: functions to copy data from old mem Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 05/10] iommu/vt-d: Add functions to load and save old re Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 06/10] iommu/vt-d: datatypes and functions used for kdump Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 07/10] iommu/vt-d: enable kdump support in iommu module Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-04-02 11:06 ` Joerg Roedel
2015-04-03 7:45 ` Li, ZhenHua [this message]
2015-04-03 7:45 ` Li, ZhenHua
2015-04-03 7:45 ` Li, ZhenHua
2015-03-19 5:36 ` [PATCH v9 08/10] iommu/vt-d: assign new page table for dma_map Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 09/10] iommu/vt-d: Copy functions for irte Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 10/10] iommu/vt-d: Use old irte in kdump kernel Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-03-19 5:36 ` Li, Zhen-Hua
2015-04-02 11:11 ` [PATCH v9 0/10] iommu/vt-d: Fix intel vt-d faults " Joerg Roedel
2015-04-02 11:11 ` Joerg Roedel
2015-04-03 7:54 ` Li, ZhenHua
2015-04-03 7:54 ` Li, ZhenHua
2015-04-03 7:54 ` Li, ZhenHua
2015-04-03 8:28 ` Dave Young
2015-04-03 8:28 ` Dave Young
2015-04-03 8:31 ` Li, ZhenHua
2015-04-03 8:31 ` Li, ZhenHua
2015-04-03 8:31 ` Li, ZhenHua
2015-04-03 8:40 ` Dave Young
2015-04-03 8:40 ` Dave Young
2015-04-03 9:01 ` Li, ZhenHua
2015-04-03 9:01 ` Li, ZhenHua
2015-04-03 9:01 ` Li, ZhenHua
2015-04-03 9:21 ` Dave Young
2015-04-03 9:21 ` Dave Young
2015-04-03 14:05 ` Li, Zhen-Hua
2015-04-03 14:05 ` Li, Zhen-Hua
2015-04-03 14:05 ` Li, Zhen-Hua
2015-04-03 14:05 ` Li, Zhen-Hua
2015-04-07 3:49 ` Dave Young
2015-04-07 3:49 ` Dave Young
2015-04-07 3:49 ` Dave Young
2015-04-05 1:54 ` Baoquan He
2015-04-05 1:54 ` Baoquan He
2015-04-05 1:54 ` Baoquan He
2015-04-07 3:46 ` Dave Young
2015-04-07 3:46 ` Dave Young
2015-04-07 9:08 ` Dave Young
2015-04-07 9:08 ` Dave Young
2015-04-07 9:55 ` Li, ZhenHua
2015-04-07 9:55 ` Li, ZhenHua
2015-04-08 3:33 ` Dave Young
2015-04-08 3:33 ` Dave Young
2015-04-08 3:33 ` Dave Young
2015-04-07 14:12 ` Don Dutile
2015-04-07 14:12 ` Don Dutile
2015-04-07 14:12 ` Don Dutile
2015-05-07 14:00 ` Dave Young
2015-05-07 14:00 ` Dave Young
2015-05-07 14:25 ` Don Dutile
2015-05-07 14:25 ` Don Dutile
2015-05-07 14:25 ` Don Dutile
2015-05-08 1:21 ` Dave Young
2015-05-08 1:21 ` Dave Young
2015-05-10 21:37 ` Don Dutile
2015-05-10 21:37 ` Don Dutile
2015-05-10 21:37 ` Don Dutile
2015-05-10 21:31 ` Don Dutile
2015-05-10 21:31 ` Don Dutile
2015-05-04 11:05 ` Joerg Roedel
2015-05-04 15:21 ` Don Dutile
2015-05-04 15:21 ` Don Dutile
2015-05-05 6:09 ` Dave Young
2015-05-05 6:09 ` Dave Young
2015-05-05 15:23 ` Joerg Roedel
2015-05-05 15:23 ` Joerg Roedel
2015-05-06 1:46 ` Dave Young
2015-05-06 1:46 ` Dave Young
2015-05-06 8:16 ` Joerg Roedel
2015-05-06 8:16 ` Joerg Roedel
2015-05-07 13:25 ` Dave Young
2015-05-07 13:25 ` Dave Young
2015-05-07 13:25 ` Dave Young
2015-05-07 13:56 ` Dave Young
2015-05-07 13:56 ` Dave Young
2015-05-11 10:11 ` Joerg Roedel
2015-05-12 5:57 ` Dave Young
2015-05-12 5:57 ` Dave Young
2015-05-12 6:41 ` Dave Young
2015-05-12 6:41 ` Dave Young
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=551E450F.4030903@hp.com \
--to=zhen-hual@hp.com \
--cc=alex.williamson@redhat.com \
--cc=bhe@redhat.com \
--cc=bhelgaas@google.com \
--cc=billsumnerlinux@gmail.com \
--cc=ddutile@redhat.com \
--cc=doug.hatch@hp.com \
--cc=dwmw2@infradead.org \
--cc=dyoung@redhat.com \
--cc=indou.takao@jp.fujitsu.com \
--cc=iommu@lists.linux-foundation.org \
--cc=ishii.hironobu@jp.fujitsu.com \
--cc=jerry.hoemann@hp.com \
--cc=joro@8bytes.org \
--cc=kexec@lists.infradead.org \
--cc=li.zhang6@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lisa.mitchell@hp.com \
--cc=rwright@hp.com \
--cc=tom.vaden@hp.com \
--cc=vgoyal@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.