On Wed, 2015-06-10 at 17:32 +0800, Li, ZhenHua wrote:
>
> Is PASID part of new specs? Is there any plan to upgrade the driver to
> support the latest vt-d specs?
Yes, and yes. I'm currently working on the latter — and the extended
page table support in 4.1 is the precursor to that work.
--
dwm
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 ba
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 bail out of any
> > copying, disable tra
On Mon, 2015-06-08 at 18:13 +0200, Joerg Roedel wrote:
> On Mon, Jun 08, 2015 at 04:50:24PM +0100, David Woodhouse wrote:
> > On Mon, 2015-06-08 at 17:29 +0200, Joerg Roedel wrote:
> > > Hmm, I also limited this functionality to kdump kernels. Do we still
> > > need to preserve these extended data
On Mon, Jun 08, 2015 at 04:50:24PM +0100, David Woodhouse wrote:
> On Mon, 2015-06-08 at 17:29 +0200, Joerg Roedel wrote:
> > Hmm, I also limited this functionality to kdump kernels. Do we still
> > need to preserve these extended data structures even when there is no
> > upstream support for them
On Mon, 2015-06-08 at 17:29 +0200, Joerg Roedel wrote:
> On Mon, Jun 08, 2015 at 03:26:23PM +0100, David Woodhouse wrote:
> > There are some interesting corner cases to handle here.
> >
> > Firstly, you don't seem to handle the case of extended root/context
> > tables (where ecap_ecs is set). You
On Mon, Jun 08, 2015 at 03:26:23PM +0100, David Woodhouse wrote:
> There are some interesting corner cases to handle here.
>
> Firstly, you don't seem to handle the case of extended root/context
> tables (where ecap_ecs is set). You need to preserve the DMA_RTADDR_RT
> bit in the Root Table Addres
On Mon, 2015-05-11 at 17:52 +0800, Li, Zhen-Hua wrote:
> 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.
Thank you very much for this.
zhenhua
From My iPhone
> 在 2015年5月30日，00:22，Joerg Roedel 写道：
>
>> On Mon, May 11, 2015 at 05:52:44PM +0800, Li, Zhen-Hua wrote:
>> Li, Zhen-Hua (10):
>> iommu/vt-d: New function to attach domain with id
>> iommu/vt-d: Items required for kdump
>> iommu/vt-d: Fu
On Mon, May 11, 2015 at 05:52:44PM +0800, Li, Zhen-Hua wrote:
> Li, Zhen-Hua (10):
> iommu/vt-d: New function to attach domain with id
> iommu/vt-d: Items required for kdump
> iommu/vt-d: Function to get existing context entry
> iommu/vt-d: functions to copy data from old mem
> iommu/vt-d
Hi Dave,
Don't worry :).
Of cause I have read your comments, but most of them contains no actual
code change request, so I did not reply them one by one.
When we are sure there is no actual code change needed, I will update
the comments and other format problems if necessary.
Regards
Zhenhua
On
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 to a new version now.
>
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 to a new version now.
So please tell me if there are still any code need to be changed.
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 p
To fix the dmar fault in running v10 with latest upstream version, added a
flush in the new function iommu_context_addr.
Thanks
Zhenhua
>
> 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,
On 05/11/15 at 05:52pm, 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
On 05/11/15 at 05:52pm, 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:
Test passed on my local wor
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: handling fault status reg 102
dmar: DMAR:[DMA Read] Reque
18 matches
Mail list logo
