On 06/10/2015 05:21 PM, Joerg Roedel wrote:
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
Is PASID part of new specs? Is there any plan to upgrade the driver to
support the latest vt-d specs?
Zhenhua
--
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
