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
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
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
Dan,
Do not need to call __iommu_free_mapped_mem() for err_unlock. for
no new elements are added into __iommu_remapped_mem when drops to
err_unlock.
Thanks
Zhenhua
On 06/02/2015 10:06 PM, Dan Carpenter wrote:
On Tue, Jun 02, 2015 at 03:45:18PM +0200, Joerg Roedel wrote:
On Tue, Jun 02, 2015
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
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
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 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:
+
+
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
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
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
___
iommu mailing list
iommu@lists.linux
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,
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
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 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
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
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
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
+ *
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
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
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
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
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
by
7/10, so please *unpatch* it from the kernel (others and the attached one
should be patched), and then test the kernel.
Regards
Zhenhua
On 12/26/2014 03:27 PM, Takao Indoh wrote:
On 2014/12/26 15:46, Li, ZhenHua wrote:
Hi Takao Indoh,
Thank you very much for your testing. I will add your
Hi Takao Indoh,
Thank you very much for your testing. I will add your update in next
version.
Also I think a flush for __iommu_update_old_root_entry is also necessary.
Currently I have no idea about your fault, does it happen before or
during its loading? Could you send me your full kernel log
:
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
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
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
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 test
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.
It should work, I
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 root correctly.
I have
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
On 10/22/2014 10:47 AM, Bjorn Helgaas wrote:
[+cc Joerg, Eric, Tom, David, iommu list]
On Wed, Oct 15, 2014 at 2:14 AM, Takao Indoh indou.ta...@jp.fujitsu.com 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
On 10/22/2014 10:47 AM, Bjorn Helgaas wrote:
[+cc Joerg, Eric, Tom, David, iommu list]
On Wed, Oct 15, 2014 at 2:14 AM, Takao Indoh indou.ta...@jp.fujitsu.com 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
Need more time to read and think about these mails. I just want to
clarify one thing: Bill has left HP, and now I inherited his works.
That's why I sent an update of his patch
https://lkml.org/lkml/2014/10/21/134
On 10/22/2014 10:47 AM, Eric W. Biederman wrote:
Bjorn Helgaas
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,
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
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
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
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
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
53 matches
Mail list logo
