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? > > 5. Keep using the old page tables before driver is loaded. > > 6. After device driver is loaded, when it issues the first dma_map command, > > free the dmar_domain structure for this device, and generate a new one, so > > that the device can be assigned a new and empty page table. > > What if there were RMRRs for this device? Don't we need to ensure that > those are present in the "new and empty page table" when we take it > over? 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. 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
