All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.