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

We *do* have upstream support. The 4.1 kernel will use the extended
root/context tables and will set the DMA_RTADDR_RTT bit in the Root
Table Address register, even though it doesn't yet actually *use* any
of the shiny new bits in the extended context tables.

So the code which copies the context tables needs to take that into

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

Yeah. We need the same thing with hardware passthrough — currently I
think we refuse to put RMRR-afflicted devices into the passthrough
domain purely because we lack the capability to install the RMRR
regions if/when we later take it *out* of the hardware passthrough
domain. Although I can't quite remember the logic there; surely if it's
RMRR-afflicted and we have iommu=pt, it'll *never* be taken out of the
1:1 domain? A device driver might come along and tell us it really is
64-bit capable and thus we might put it *in* to the passthrough domain
where previously we'd kept it out... but taking it *out*... ?

[unhandled content-type:application/x-pkcs7-signature]
 \ /
  Last update: 2015-06-08 18:21    [W:0.085 / U:1.552 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site