On Mon, 2015-06-08 at 18:13 +0200, Joerg Roedel wrote: > On Mon, Jun 08, 2015 at 04:50:24PM +0100, David Woodhouse wrote: > > On Mon, 2015-06-08 at 17:29 +0200, Joerg Roedel wrote: > > > 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. > > Right, I missed that until now. So what the code with my changes does > is, it sets the DMA_RTADDR_RTT bit as it would do on a normal boot. But > unlike the root entry table address, this bit can not be changed while > translation is active. > > So I think we need to read out that bit when we find translation enabled > and if it is different from what we would set it to, we bail out of any > copying, disable translation and proceed as in a normal boot. Given that this is only for kdump and not the general case of kexec, that's probably tolerable. Of course we do still need to make it *not* broken for the case where DMA_RTADDR_RTT is set, as it is at the moment. And I suspect if we're doing that, it might be simple enough to make it convert to/from the extended page tables. I don't think we want to preserve PASID tables; only the "second level" (i.e. traditional) translation. So we could happily pull the page table pointer out of either kind of context entry, and install it into either kind. I think there's a simple mapping of translation types too. I need to sort out the translation types when adding the real PASID support (imminently!) anyway. -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
