On 04/03/15 at 05:01pm, Li, ZhenHua wrote:
> 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
> t
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 these faults:
>
> dmar: DRHD: handlin
> To fix this problem, we modifies the behaviors of the intel vt-d in the
> crashdump kernel:
>
> For DMA Remapping:
> 1. To accept the vt-d hardware in an active state,
> 2. Do not disable and re-enable the translation, keep it enabled.
> 3. Use the old root entry table, do not rewrite the RTA r
The hardware will do some verification, but not completely. If people think
the OS should also do this, then it should be another patchset, I think.
Thanks
Zhenhua
> 在 2015年4月3日，17:21，Dave Young 写道：
>
>> On 04/03/15 at 05:01pm, Li, ZhenHua wrote:
>> Hi Dave,
>>
>> There may be some possibil
Hello,
We are eventually working on the vSMMU implementation. Relying on the talk
Will Deacon gave at the Linux Plumbers IOMMU Microconference on October
2014 (http://linuxplumbersconf.org/2014/ocw/proposals/2019), I tried the
vSMMU initialization.
I have a question about the KVM_DEV_ARM_SMMU_V2_
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/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 thes
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
curr
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 intel-iommu
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
10 matches
Mail list logo
