lkml.org 
[lkml]   [2015]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v11 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
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 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.

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 yet?

> > 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?

That is still a problem, but not specific to this patch-set. RMRRs will
not be restored, because domains allocated out of the DMA-API path will
not get any RMRR mappings. This is also a problem with device hotplug
(unplug a device with RMRRs and replug it in and the RMRR mappings will
be gone).

I agree that this needs to be fixed.


Joerg



\
 
 \ /
  Last update: 2015-06-08 18:21    [W:0.328 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site