[PATCH v11 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel

David Woodhouse dwmw2 at infradead.org
Mon Jun 8 07:26:23 PDT 2015


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. Use the old root entry table, do not rewrite the RTA register.
> 4. Malloc and use new context entry table, copy data from the old ones that
>    used by the old kernel.

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 Address register, surely?

I think we also need to cope with inheriting page tables from a kernel
that *doesn't* use extended page tables, even on hardware that supports
it. Which means the use of extended page tables in the new kernel would
need to be contingent on something *other* than the pure hardware
capabilities.

> 5. Keep using the old page tables before driver is loaded.
> 6. After device driver is loaded, when it issues the first dma_map command, 
>    free the dmar_domain structure for this device, and generate a new one, so 
>    that the device can be assigned a new and empty page table. 

What if there were RMRRs for this device? Don't we need to ensure that
those are present in the "new and empty page table" when we take it
over?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20150608/3f98542d/attachment.bin>


More information about the kexec mailing list