Hi Baoquan,
Thank you very much for your review. But according to the latest
discussion, the page tables will not be copied from old kernel. We keep
using the old page tables before driver is loaded. So there are many
changes in next version;
See my comments.
On 01/15/2015 11:28 AM, Baoquan He
According to Takao Indoh's testing, seems adding flush after loading old
irte and updating old irte does not fix the dmar faults.
According to Takao Indoh's log and your log, the faults happens while
and after driver is loaded. Maybe I am using incorrect code in 08/10.
On 01/06/2015 02:37
Thank you very much for your help.
I have found there are several places need flush, and I will send a new
version
of this patchset with the flush functions.
Regards
Zhenhua
On 01/06/2015 08:18 AM, Takao Indoh wrote:
On 2014/12/29 12:15, Li, ZhenHua wrote:
Hi Takao Indoh,
Happy New Year
On 01/12/2015 05:07 PM, Baoquan He wrote:
On 01/12/15 at 04:00pm, Li, ZhenHua wrote:
Comparing to v7, this version adds only a few lines code:
In function copy_page_table,
+ __iommu_flush_cache(iommu, phys_to_virt(dma_pte_next),
+ VTD_PAGE_SIZE
Comparing to v7, this version adds only a few lines code:
In function copy_page_table,
+ __iommu_flush_cache(iommu, phys_to_virt(dma_pte_next),
+ VTD_PAGE_SIZE);
On 01/12/2015 03:06 PM, Li, Zhen-Hua wrote:
This patchset is an update of Bill
Many thanks to Takao Indoh and Baoquan He, for your testing on more
different systems.
The calling of flush functions are added to this version.
The usage of __iommu_flush_cache function :
1. Fixes a dump on Takao's system.
2. Reduces the count of faults on Baoquan's system.
Regards
Zhenhua
.
Regards
Zhenhua
On 01/07/2015 01:02 PM, Baoquan He wrote:
On 01/07/15 at 12:11pm, Li, ZhenHua wrote:
Many thanks to Takao Indoh and Baoquan He, for your testing on more
different systems.
The calling of flush functions are added to this version.
The usage of __iommu_flush_cache function :
1
Well, that's quite good news.
Looking forward Takao's testing on his system.
Regards
Zhenhua
On 01/07/2015 04:28 PM, Baoquan He wrote:
On 01/07/15 at 01:25pm, Li, ZhenHua wrote:
It is same as the last one I send to you yesterday.
The continuous memory that needed for data in this patchset:
RE
On 01/12/2015 11:18 PM, Joerg Roedel wrote:
On Mon, Jan 12, 2015 at 03:06:19PM +0800, Li, Zhen-Hua wrote:
Allow specification of the domain-id for the new domain.
This patch only adds the 'did' parameter to iommu_attach_domain()
and modifies all of its callers to specify the default value of -1
On 01/12/2015 11:22 PM, Joerg Roedel wrote:
On Mon, Jan 12, 2015 at 03:06:20PM +0800, Li, Zhen-Hua wrote:
+
+#ifdef CONFIG_CRASH_DUMP
+
+/*
+ * Fix Crashdump failure caused by leftover DMA through a hardware IOMMU
+ *
+ * Fixes the crashdump kernel to deal with an active iommu and legacy
+ *
Hi Joerg,
This is quite strange. I checked the patches from patch 01 to 10 using
./scripts/checkpatch.pl under the kernel source directory, but got 0
errors and 0 warning. Only some white spaces in the cover letter 00,
but is could not be checked by this script.
But I checked the
Hi Dave,
There may be some possibilities that the old iommu data is corrupted by
some other modules. Currently we do not have a better solution for the
dmar faults.
But I think when this happens, we need to fix the module that corrupted
the old iommu data. I once met a similar problem in normal
Hi Feng Wu,
In my patchset, I created a new member ir_table-base_old_phys; In the
normal kernel, everything is the same. In kdump kernel, ir_table-base
is used for a buffer, and ir_table-base_old_phys is the physical
address of the tables used by the old kernel, also being used by the
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
On 04/03/2015 04:28 PM, Dave Young wrote:
On 03/19/15 at 01:36pm, Li, Zhen-Hua wrote:
This patchset is an update of Bill Sumner's patchset, implements a fix for:
If a kernel boots with intel_iommu=on on a system that supports intel vt-d,
when a panic happens, the kdump kernel will boot with
Hi Dave,
I found the old mail:
http://lkml.iu.edu/hypermail/linux/kernel/1410.2/03584.html
Please check this and you will find the discussion.
Regards
Zhenhua
On 04/15/2015 02:48 PM, Dave Young wrote:
On 04/15/15 at 01:47pm, Li, ZhenHua wrote:
On 04/15/2015 08:57 AM, Dave Young wrote:
Again
Hi Baoquan,
If old tables are corrupted, we will see the DMAR faults or INTR faults
(which we have seen), or some other error messages. Most of these
messages are from hardware. This means, hardware will do some check when
running. But I don't think hardware will completely check the
tables.
Hi baoquan,
Could you paste the kernel log of the first kernel ?
Thanks
Zhenhua
On 05/03/2015 04:55 PM, Baoquan He wrote:
On 04/29/15 at 07:20pm, Baoquan He wrote:
Bad news, I rebuilt a kernel with your patchset on 4.0.0+ (this commit
f614c81). Now dmar fault is seen again.
The lspci log and
Dave,
This patchset will only write root tables in old kernel, if it is
corrupted, faults will also happen in old kernel, and hardware would
mark it. So things will not go worse..
Thanks
Zhenhua
On 05/06/2015 09:51 AM, Dave Young wrote:
On 05/05/15 at 05:31pm, Joerg Roedel wrote:
On Tue,
It is called in
static int copy_root_entry_table(struct intel_iommu *iommu);
On 05/07/2015 03:49 PM, Baoquan He wrote:
On 04/10/15 at 04:42pm, Li, Zhen-Hua wrote:
Add some functions to copy the data from old kernel.
These functions are used to copy context tables and page tables.
To avoid
, Baoquan He wrote:
On 05/04/15 at 11:06am, Li, ZhenHua wrote:
Hi baoquan,
Could you paste the kernel log of the first kernel ?
Please let me know when you have worked this issue out.
Thanks,
Joerg
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hi Dave,
iommu-root_entry_old_virt is used to store the mapped old rta.
iommu-root_entry_old_phys is used to store the physical address stored
in registers.
So we must not free/unmap iommu-root_entry_old_phys .
Zhenhua
On 05/13/2015 04:56 PM, Baoquan He wrote:
+
+
Hi Baoquan,
I am using a list here to store all the mapped addresses, and unmap them
out of iounmap.
About the reason, please check the old mails. I cannot remember the
detailed reasons.
Thanks
Zhenhua
On 05/13/2015 05:00 PM, Baoquan He wrote:
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
On 05/12/2015 04:37 PM, Dave Young wrote:
Seems the subject was truncated? Maybe re means root entry? Then please fix it
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Add functions to load root entry table from old kernel, and to save updated
root entry table.
Add two member in struct
One thing must be pointed out:
There is a known issue that hpsa driver cannot work well in kdump
kernel. And this patchset is not intended to fix this problem.
So this patchset cannot work with HP smart array devices which need hpsa
driver.
On 05/11/2015 05:52 PM, Li, Zhen-Hua wrote:
This
+static u8 g_translation_pre_enabled;
Hi Zhenhua,
I haven't checked patch one by one, am going through the code flow.
About g_translation_pre_enabled, I don't think it's necessary to define
it as a global variable. Both its assignment and judgement are in
init_dmars(). In this situation a
On 05/12/2015 04:17 PM, Dave Young wrote:
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Add context entry functions needed for kdump.
+/*
+ * Fix Crashdump failure caused by leftover DMA through a hardware IOMMU
+ *
+ * Fixes the crashdump kernel to deal with an active iommu and legacy
+ * DMA
On 05/19/2015 09:13 AM, Dave Young wrote:
Hi,
On 05/18/15 at 06:05pm, Li, ZhenHua wrote:
Hi Joerg,
Testing from HP: passed.
Testing from He Baoquan(Redhat): passed
The problem that dmar fault came again when running v10 with latest
kernel is fixed.
And I think there is no need to update the code
.
Thanks
Zhenhua
On 05/13/2015 09:54 AM, Li, ZhenHua wrote:
One thing must be pointed out:
There is a known issue that hpsa driver cannot work well in kdump
kernel. And this patchset is not intended to fix this problem.
So this patchset cannot work with HP smart array devices which need hpsa
On 04/15/2015 08:57 AM, Dave Young wrote:
Again, I think it is bad to use old page table, below issues need consider:
1) make sure old page table are reliable across crash
2) do not allow writing oldmem after crash
Please correct me if I'm wrong, or if above is not doable I think I will vote
On 04/07/2015 05:08 PM, Dave Young wrote:
On 04/07/15 at 11:46am, Dave Young wrote:
On 04/05/15 at 09:54am, Baoquan He wrote:
On 04/03/15 at 05:21pm, Dave Young wrote:
On 04/03/15 at 05:01pm, Li, ZhenHua wrote:
Hi Dave,
There may be some possibilities that the old iommu data is corrupted
On 05/21/2015 02:54 PM, Baoquan He wrote:
On 05/21/15 at 09:27am, Li, ZhenHua wrote:
Hi Baoquan,
In the early version of this patchset, old page tables are used by new
kernel. But as discussed, we need to make kernel use new pages when
there is a new dma request , so we need to unmap the pages
Hi Baoquan,
In the early version of this patchset, old page tables are used by new
kernel. But as discussed, we need to make kernel use new pages when
there is a new dma request , so we need to unmap the pages which were
mapped in old kernel, and this is what this patch does.
Thanks
Zhenhua
Finished testing on my HP huge system, SuperDome X.
It works well.
Thanks
Zhenhua
On 06/05/2015 10:10 PM, Joerg Roedel wrote:
Hey,
here are a couple of patches to fix the fall-out from the
patch set fixing the kdump faults with VT-d enabled. A few
important issues have been fixed:
*
My pleasure, thanks.
Zhenhua
On 06/08/2015 04:23 PM, Joerg Roedel wrote:
On Mon, Jun 08, 2015 at 04:06:45PM +0800, Li, ZhenHua wrote:
Finished testing on my HP huge system, SuperDome X.
It works well.
Thanks for testing this, Zhen-Hua. Might I add your Tested-by to the
patches
On 06/10/2015 05:21 PM, Joerg Roedel wrote:
On Tue, Jun 09, 2015 at 01:55:50PM +0100, David Woodhouse wrote:
On Mon, 2015-06-08 at 18:13 +0200, Joerg Roedel wrote:
So I think we need to read out that bit when we find translation enabled
and if it is different from what we would set it to, we
On 06/23/2015 10:38 PM, David Woodhouse wrote:
On Tue, 2015-06-23 at 16:06 +0200, Joerg Roedel wrote:
On Tue, Jun 23, 2015 at 02:31:30PM +0100, David Woodhouse wrote:
However, it's still fairly gratuitous for all non-broken hardware, and
will tend to hide hardware and driver bugs during
Hi all,
I see Joerg has backported it to sles12 in the commoent of novel
bugzilla 856382, so I will only backport it to redhat el.
Thanks
Zhenhua
On 06/13/2015 02:47 PM, Joerg Roedel wrote:
Hi,
as David Woodhouse pointed out, my fixes and cleanups for
the original patch-set turned out to be a
I have not seen such a bug yet . but obviously a '=' should be used when
you want to set a value.
for example, if x != 0,
x=10
and
x|=10
will cause different result.
ZhenHua
On 01/07/2014 10:41 PM, Joerg Roedel wrote:
On Fri, Dec 20, 2013 at 04:45:01PM +0800, Li, Zhen-Hua
This patch is sent again because a ';' was missed in my last mail.
> + context->asr = value >> VTD_PAGE_SHIFT
I corrected it and created a new one. And it is tested .
Please use the latest one.
Sorry for that.
ZhenHua
On 01/10/2014 04:27 PM, Li, Zhen-Hua wrote:
There is a structure named
Yes, that's the problem. And some other structures like this, see "union
irte".
On 12/26/2013 01:12 PM, Wu, Feng wrote:
I think if using |= operation, it should use &= operation to clear those
bits first.
Thanks,
Feng
*From:*iommu-boun...@lists.linux-foundation.org
Hi,
I found it was incorrect. So please IGNORE this patch.
Sorry for that.
On 12/09/2013 11:20 AM, Li, Zhen-Hua wrote:
In function tty_release, there are two unlock not called while
breaking from a while. This may cause problems.
This patch fixed this problem , adding the two unlocks before
The comment is trying to explain why add a lock here.
On 04/19/2014 03:01 AM, Sergei Shtylyov wrote:
Hello.
On 04/16/2014 11:08 AM, Li, Zhen-Hua wrote:
From: "Li, Zhen-Hua"
As netif_running is called in netif_device_attach/detach. There
should be
rtnl_lock/unlock called, to avoid dev
Any update?
On 07/01/2014 01:02 AM, Heinrich Schuchardt wrote:
On 30.06.2014 05:16, Li, Zhen-Hua wrote:
There is a warning when run "make menuconfig".
scripts/kconfig/menu.c: In function ‘get_symbol_str’:
scripts/kconfig/menu.c:591:18: warning: ‘jump’ may be used
uninitialized in
this
Heinrich,
Thank you very much for reviewing. But seems the maintainer will not
accept it.
Zhenhua
On 07/15/2014 12:30 AM, Heinrich Schuchardt wrote:
On 01.07.2014 01:10, Li, Zhen-Hua wrote:
When malloc for jump,
if (head && location) {
jump = xmalloc(sizeof(struct jump_key));
}
Hi Peter,
This bug was founded in RHEL 6, kernel version 2.6.32.
But I also checked the file tty_io.c in latest kernel, not all the code
protected by tty_lock(tty).
For example, in function tty_del_file,
if (--tty->count < 0) {
}
and
tty_del_file(filp);
are not surrounded by
Hi Jiri,
You are right, I tested the latest kernel, did not see this bug.
So I will only submit this patch to Redhat.
Thanks
Zhenhua
On 07/15/2014 05:16 PM, Jiri Slaby wrote:
Hi,
On 07/15/2014 11:08 AM, Li, ZhenHua wrote:
This bug was founded in RHEL 6, kernel version 2.6.32.
But I also
I found there are more data need to be cleared for the dump kernel.
So please ignore this patch, I will send out another one.
Thanks
Zhenhua
On 08/19/2014 07:59 AM, Li, Zhen-Hua wrote:
My debugging result is this:
1. Clear the old root entry table, dump kernel will choose another
memory
On my system, error message:
[4.322008] dmar: DRHD: handling fault status reg 2
[4.327484] dmar: DMAR:[DMA Read] Request device [21:00.0] fault addr
fff66000
[4.327484] DMAR:[fault reason 01] Present bit in root entry is clear
fault happens on device : 21:00.0
To describe this
According to Takao Indoh's testing, seems adding flush after loading old
irte and updating old irte does not fix the dmar faults.
According to Takao Indoh's log and your log, the faults happens while
and after driver is loaded. Maybe I am using incorrect code in 08/10.
On 01/06/2015 02:37
Many thanks to Takao Indoh and Baoquan He, for your testing on more
different systems.
The calling of flush functions are added to this version.
The usage of __iommu_flush_cache function :
1. Fixes a dump on Takao's system.
2. Reduces the count of faults on Baoquan's system.
Regards
Zhenhua
.
Regards
Zhenhua
On 01/07/2015 01:02 PM, Baoquan He wrote:
On 01/07/15 at 12:11pm, Li, ZhenHua wrote:
Many thanks to Takao Indoh and Baoquan He, for your testing on more
different systems.
The calling of flush functions are added to this version.
The usage of __iommu_flush_cache function :
1
Well, that's quite good news.
Looking forward Takao's testing on his system.
Regards
Zhenhua
On 01/07/2015 04:28 PM, Baoquan He wrote:
On 01/07/15 at 01:25pm, Li, ZhenHua wrote:
It is same as the last one I send to you yesterday.
The continuous memory that needed for data in this patchset:
RE
reason, so I will fix it like fixing the DMAR
faults: Do NOT disable and re-enable the interrupt remapping, try to
use data from old kernel.
Thanks
Zhenhua
On 11/17/2014 09:38 PM, Joerg Roedel wrote:
On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote:
I am working following your
Add Joerg to CC list. For it is also related to iommu module.
Joerg,
There was a try for this dmar fault,
https://lkml.org/lkml/2014/8/18/118
This patch is trying to fix the same thing.
Zhenhua
On 09/30/2014 02:09 PM, Li, Zhen-Hua wrote:
On a HP system with Intel Corporation 82599
:
On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote:
I am working following your directions:
1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry
table, and do NOT disable-enable iommu. Other data will be copied.
2. When a device driver issues the first dma_map command
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
Hi Joerg,
This is quite strange. I checked the patches from patch 01 to 10 using
./scripts/checkpatch.pl under the kernel source directory, but got 0
errors and 0 warning. Only some white spaces in the cover letter 00,
but is could not be checked by this script.
But I checked the
Hi Feng Wu,
In my patchset, I created a new member ir_table->base_old_phys; In the
normal kernel, everything is the same. In kdump kernel, ir_table->base
is used for a buffer, and ir_table->base_old_phys is the physical
address of the tables used by the old kernel, also being used by the
On 04/03/2015 04:28 PM, Dave Young wrote:
On 03/19/15 at 01:36pm, Li, Zhen-Hua wrote:
This patchset is an update of Bill Sumner's patchset, implements a fix for:
If a kernel boots with intel_iommu=on on a system that supports intel vt-d,
when a panic happens, the kdump kernel will boot with
Hi Dave,
There may be some possibilities that the old iommu data is corrupted by
some other modules. Currently we do not have a better solution for the
dmar faults.
But I think when this happens, we need to fix the module that corrupted
the old iommu data. I once met a similar problem in normal
On 04/07/2015 05:08 PM, Dave Young wrote:
On 04/07/15 at 11:46am, Dave Young wrote:
On 04/05/15 at 09:54am, Baoquan He wrote:
On 04/03/15 at 05:21pm, Dave Young wrote:
On 04/03/15 at 05:01pm, Li, ZhenHua wrote:
Hi Dave,
There may be some possibilities that the old iommu data is corrupted
Hi Baoquan,
In the early version of this patchset, old page tables are used by new
kernel. But as discussed, we need to make kernel use new pages when
there is a new dma request , so we need to unmap the pages which were
mapped in old kernel, and this is what this patch does.
Thanks
Zhenhua
On 05/21/2015 02:54 PM, Baoquan He wrote:
On 05/21/15 at 09:27am, Li, ZhenHua wrote:
Hi Baoquan,
In the early version of this patchset, old page tables are used by new
kernel. But as discussed, we need to make kernel use new pages when
there is a new dma request , so we need to unmap the pages
Hi Dave,
I found the old mail:
http://lkml.iu.edu/hypermail/linux/kernel/1410.2/03584.html
Please check this and you will find the discussion.
Regards
Zhenhua
On 04/15/2015 02:48 PM, Dave Young wrote:
On 04/15/15 at 01:47pm, Li, ZhenHua wrote:
On 04/15/2015 08:57 AM, Dave Young wrote:
Again
Dave,
This patchset will only write root tables in old kernel, if it is
corrupted, faults will also happen in old kernel, and hardware would
mark it. So things will not go worse..
Thanks
Zhenhua
On 05/06/2015 09:51 AM, Dave Young wrote:
On 05/05/15 at 05:31pm, Joerg Roedel wrote:
On Tue,
On 05/12/2015 04:17 PM, Dave Young wrote:
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Add context entry functions needed for kdump.
+/*
+ * Fix Crashdump failure caused by leftover DMA through a hardware IOMMU
+ *
+ * Fixes the crashdump kernel to deal with an active iommu and legacy
+ * DMA
On 05/12/2015 04:37 PM, Dave Young wrote:
Seems the subject was truncated? Maybe "re" means root entry? Then please fix it
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Add functions to load root entry table from old kernel, and to save updated
root entry table.
Add two member in struct
One thing must be pointed out:
There is a known issue that hpsa driver cannot work well in kdump
kernel. And this patchset is not intended to fix this problem.
So this patchset cannot work with HP smart array devices which need hpsa
driver.
On 05/11/2015 05:52 PM, Li, Zhen-Hua wrote:
This
+static u8 g_translation_pre_enabled;
Hi Zhenhua,
I haven't checked patch one by one, am going through the code flow.
About g_translation_pre_enabled, I don't think it's necessary to define
it as a global variable. Both its assignment and judgement are in
init_dmars(). In this situation a
Hi Dave,
iommu->root_entry_old_virt is used to store the mapped old rta.
iommu->root_entry_old_phys is used to store the physical address stored
in registers.
So we must not free/unmap iommu->root_entry_old_phys .
Zhenhua
On 05/13/2015 04:56 PM, Baoquan He wrote:
+
+
Hi Baoquan,
I am using a list here to store all the mapped addresses, and unmap them
out of iounmap.
About the reason, please check the old mails. I cannot remember the
detailed reasons.
Thanks
Zhenhua
On 05/13/2015 05:00 PM, Baoquan He wrote:
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Hi Baoquan,
If old tables are corrupted, we will see the DMAR faults or INTR faults
(which we have seen), or some other error messages. Most of these
messages are from hardware. This means, hardware will do some check when
running. But I don't think hardware will completely check the
tables.
Finished testing on my HP huge system, SuperDome X.
It works well.
Thanks
Zhenhua
On 06/05/2015 10:10 PM, Joerg Roedel wrote:
Hey,
here are a couple of patches to fix the fall-out from the
patch set fixing the kdump faults with VT-d enabled. A few
important issues have been fixed:
*
My pleasure, thanks.
Zhenhua
On 06/08/2015 04:23 PM, Joerg Roedel wrote:
On Mon, Jun 08, 2015 at 04:06:45PM +0800, Li, ZhenHua wrote:
Finished testing on my HP huge system, SuperDome X.
It works well.
Thanks for testing this, Zhen-Hua. Might I add your Tested-by to the
patches
.
Thanks
Zhenhua
On 05/13/2015 09:54 AM, Li, ZhenHua wrote:
One thing must be pointed out:
There is a known issue that hpsa driver cannot work well in kdump
kernel. And this patchset is not intended to fix this problem.
So this patchset cannot work with HP smart array devices which need hpsa
On 05/19/2015 09:13 AM, Dave Young wrote:
Hi,
On 05/18/15 at 06:05pm, Li, ZhenHua wrote:
Hi Joerg,
Testing from HP: passed.
Testing from He Baoquan(Redhat): passed
The problem that dmar fault came again when running v10 with latest
kernel is fixed.
And I think there is no need to update the code
On 01/12/2015 11:18 PM, Joerg Roedel wrote:
On Mon, Jan 12, 2015 at 03:06:19PM +0800, Li, Zhen-Hua wrote:
Allow specification of the domain-id for the new domain.
This patch only adds the 'did' parameter to iommu_attach_domain()
and modifies all of its callers to specify the default value of -1
On 01/12/2015 11:22 PM, Joerg Roedel wrote:
On Mon, Jan 12, 2015 at 03:06:20PM +0800, Li, Zhen-Hua wrote:
+
+#ifdef CONFIG_CRASH_DUMP
+
+/*
+ * Fix Crashdump failure caused by leftover DMA through a hardware IOMMU
+ *
+ * Fixes the crashdump kernel to deal with an active iommu and legacy
+ *
Hi Baoquan,
Thank you very much for your review. But according to the latest
discussion, the page tables will not be copied from old kernel. We keep
using the old page tables before driver is loaded. So there are many
changes in next version;
See my comments.
On 01/15/2015 11:28 AM, Baoquan He
Comparing to v7, this version adds only a few lines code:
In function copy_page_table,
+ __iommu_flush_cache(iommu, phys_to_virt(dma_pte_next),
+ VTD_PAGE_SIZE);
On 01/12/2015 03:06 PM, Li, Zhen-Hua wrote:
This patchset is an update of Bill
On 01/12/2015 05:07 PM, Baoquan He wrote:
On 01/12/15 at 04:00pm, Li, ZhenHua wrote:
Comparing to v7, this version adds only a few lines code:
In function copy_page_table,
+ __iommu_flush_cache(iommu, phys_to_virt(dma_pte_next),
+ VTD_PAGE_SIZE
On 10/17/2014 05:44 PM, Eric W. Biederman wrote:
"Li, Zhen-Hua" writes:
This is an update of the patch
https://lkml.org/lkml/2014/10/10/37
This patch is doing the reset works before the kdump kernel boots.
If I have said it once I have said it a thousand times.
Nacked-by: "Eric W.
On 10/20/2014 07:20 AM, Gavin Shan wrote:
On Fri, Oct 17, 2014 at 02:44:43AM -0700, Eric W. Biederman wrote:
"Li, Zhen-Hua" writes:
This is an update of the patch
https://lkml.org/lkml/2014/10/10/37
This patch is doing the reset works before the kdump kernel boots.
If I have said
Hi Takao Indoh,
According to this discussion
https://lkml.org/lkml/2014/10/17/107
It seems that we can not do the resetting on the first kernel. It can
only be called during kdump kernel boots.
Thanks
Zhenhua
On 10/15/2014 04:14 PM, Takao Indoh wrote:
> (2014/10/14 18:34), Li, Zhen
On 10/20/2014 09:46 AM, Li, ZhenHua wrote:
On 10/20/2014 07:20 AM, Gavin Shan wrote:
On Fri, Oct 17, 2014 at 02:44:43AM -0700, Eric W. Biederman wrote:
"Li, Zhen-Hua" writes:
This is an update of the patch
https://lkml.org/lkml/2014/10/10/37
This patch is doing the reset wo
Minfei,
Thanks for your testing.
On my system, I got error messages:
[8.019096] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[8.019617] dmar: DRHD: handling fault status reg 102
[8.019621] dmar: DMAR:[DMA Read] Request device [01:00.0] fault addr
fff6a000
[
On 11/13/2014 09:37 PM, Baoquan He wrote:
On 11/13/14 at 05:06pm, Li, ZhenHua wrote:
Minfei,
Thanks for your testing.
On my system, I got error messages:
[8.019096] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[8.019617] dmar: DRHD: handling fault status reg 102
dma_map command for a
device, we assign a new and empty page-table, thus removing all
mappings from the old kernel for the device.
Please let me know if I get something wrong.
Thanks
Zhenhua
On 11/06/2014 04:06 PM, Li, ZhenHua wrote:
> Thank you very much for your testing and fix. I will also t
1st step shows we should NOT disable the iommu when it is already
enabled. But current code does disable-enable. So there is still works
to do.
The original kernel does a disable and re-enable , Bill's patchset
removed the disable operation.
I think step 2 is necessary, because when the
Hi Joerg,
While debugging Bill's patches, I found this problem:
When copying iommu data from old kernel to the kdump kernel, the
original function context_set_address_root() may cause kdump kernel
using incorrect address root value.
So I created this patch to fix it.
Zhenhua
On 11/05/2014
Yes, that's it. The function context_set_address_root does not set the
address root correctly.
I have created another patch for it, see
https://lkml.org/lkml/2014/11/5/43
Thanks
Zhenhua
On 11/06/2014 09:31 AM, Takao Indoh wrote:
> Hi Zhenhua, Baoquan,
>
> (2014/10/22 19:05), Baoquan He
This patch does the same thing as you said in your mail.
It should work, I have tested on my HP huge system.
On 11/06/2014 09:48 AM, Takao Indoh wrote:
> (2014/11/06 10:35), Li, ZhenHua wrote:
>> Yes, that's it. The function context_set_address_root does not set the
>> address
Thank you very much for your testing and fix. I will also test it on my
system.
I will let you know when I get a result.
Regards
Zhenhua
On 11/06/2014 03:51 PM, Takao Indoh wrote:
> (2014/11/06 11:11), Li, ZhenHua wrote:
>> This patch does the same thing as you said in your mail.
>
I tested on the latest stable version 3.17, it works well.
On 10/10/2014 03:13 PM, Li, Zhen-Hua wrote:
On a HP system with Intel vt-d supported and many PCI devices on it,
when kernel crashed and the kdump kernel boots with intel_iommu=on,
there may be some unexpected DMA requests on this
David, Joerg,
I plan to merge this patch set with 3.17 stable kernel, and split this
patch set into two :
1. The core part, including the changed functions, like [Patch 4/8],
[Patch 8/8].
2. For the formatting issues, like [Patch 1/8],[Patch 3/8], including
the changes for code formations,
for latest stable kernel 3.17.
Thanks
Zhenhua
On 10/15/2014 04:14 PM, Takao Indoh wrote:
> (2014/10/14 18:34), Li, ZhenHua wrote:
>> I tested on the latest stable version 3.17, it works well.
>>
>> On 10/10/2014 03:13 PM, Li, Zhen-Hua wrote:
>>> On a HP system with
Add Tom to CC list.
On 10/15/2014 04:10 PM, Li, ZhenHua wrote:
David, Joerg,
I plan to merge this patch set with 3.17 stable kernel, and split this
patch set into two :
1. The core part, including the changed functions, like [Patch 4/8],
[Patch 8/8].
2. For the formatting issues, like [Patch 1/8
well, then I will create a patch for ALL pcie devices.
On 10/03/2014 10:28 PM, Alexander Duyck wrote:
On 10/02/2014 08:09 AM, Bjorn Helgaas wrote:
On Tue, Sep 30, 2014 at 12:15 AM, Li, ZhenHua wrote:
Add Joerg to CC list. For it is also related to iommu module.
Joerg,
There was a try
On 06/23/2015 10:38 PM, David Woodhouse wrote:
On Tue, 2015-06-23 at 16:06 +0200, Joerg Roedel wrote:
On Tue, Jun 23, 2015 at 02:31:30PM +0100, David Woodhouse wrote:
However, it's still fairly gratuitous for all non-broken hardware, and
will tend to hide hardware and driver bugs during
1 - 100 of 164 matches
Mail list logo
