On Tue, Jun 09, 2015 at 01:55:50PM +0100, David Woodhouse wrote: > On Mon, 2015-06-08 at 18:13 +0200, Joerg Roedel wrote: > > 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. Yes, I just sent a patch for this and will include it into my x86/vt-d branch if not objections come in. > 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. What happens when we take away the PASID tables from a device? Can it also go into some failure state? When doing this, we need at least setup the page request queue before we copy over anything and change the root-entry. Then we can handle any faults that are caused by this and tell the device to not try further. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
