Hi Baoquan, On Sun, Nov 12, 2017 at 04:04:26PM +0800, Baoquan He wrote: > Solution: > 1) Remove the code which support GART IOMMU when it's not enabled in > BIOS. This has been done in the new generation of hardware IOMMU like > intel vt-d IOMMU and amd-Vi IOMMU. We should not make GART IOMMU be > exceptional. Wouldn't this break old machines with actual AGP and misconfigured/bugg BIOSes? Wasn't that the reason why we have the workaround of mapping the hole over real memory? > 2) Remove those pages from mm subsystem since they are not seen any more > though they have been added into mm subsystem, because CPU can't see > them. not exactly sure I understand this... they are reserved by the memblock allocater, thus preventing any further use by any mm code. > 3) Remove the apreture region from /proc/iomem so that pages in that > region can't be seen by kdump kernel. This is easier, but just a work > around. I like this idea, but won't this cause pci_claim_resource() fail after the call to pci_find_parent_resource() ? See my previous mail. Bad thing is, we don't want to break random old AGP hardware, but at the same time, it's now too rare to properly test this. So wouldn't it be better to fix the problem at least for the kexec_file case using my original patch? A possible hack for the old kexec syscall might be to make /proc/iomem list the "GART" region without it being present in the iomem resource database. kexec-tools has working code to deal with the GART region, but the kernel no longer includes it in /proc/iomem. Or maybe a cleaner solution than special-casing the "GART" region into /proc/iomem would be to introduce a new type of iomem resource that would be visible in /proc/iomem but would allow other resources to be requested even when overlapping the region of this special resource? This way, we could insert the "GART" resource when allocating the hole but later, when an actual AGP driver requests the range during PCI enumeration, the "GART" resource would be overwrtiten by the actual PCI resource. -- Jiri Bohac <jbohac at suse.cz> SUSE Labs, Prague, Czechia
