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 -------------- 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/ec6a58d7/attachment.bin>
