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

From: David Woodhouse <dwmw2@infradead.org>
To: Joerg Roedel <joro@8bytes.org>
Cc: bhe@redhat.com, tom.vaden@hp.com, rwright@hp.com,
	linux-pci@vger.kernel.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, lisa.mitchell@hp.com,
	iommu@lists.linux-foundation.org, "Li,
	Zhen-Hua" <zhen-hual@hp.com>,
	doug.hatch@hp.com, ishii.hironobu@jp.fujitsu.com,
	bhelgaas@google.com, billsumnerlinux@gmail.com, li.zhang6@hp.com,
	dyoung@redhat.com, vgoyal@redhat.com
Subject: Re: [PATCH v11 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
Date: Mon, 08 Jun 2015 16:50:24 +0100	[thread overview]
Message-ID: <1433778624.2952.82.camel@infradead.org> (raw)
In-Reply-To: <20150608152957.GW20384@8bytes.org>

[-- Attachment #1: Type: text/plain, Size: 2248 bytes --]

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

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

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]