On Tue, Nov 07, 2017 at 07:39:56PM +0800, Baoquan He wrote: > I saw you defined the variable as xx_stolen_xx, does it mean that the > memory region where aperture located will be stolen from memory domain? > I am wondering if it will cause error when access this region from direct > mapping since allocate_aperture() is called in pci_iommu_alloc(), while > in setup_arch() we have built the direct mapping for all system > ram. Did I miss anything? yes, I believe accessing it through the direct mapping would cause the error; but the range is allocated by the memblock allocator and never given back, which effectively steals it from any other use; The memory will never be given to any user by any subsequent allocation, so nothing will access it. > Anyway, if it should be excluded from crash memory region, can we dig it > away from /proc/iomem so that it's a hole in /proc/vmcore? Like this, we Not sure this would work. In bko#72201, marking the range as used caused pci_claim_resource() to error out with -EBUSY after request_resource_conflict() (the error message has changed in 29003be but the logic remains). My (possibly wrong?) reading of pci_claim_resource() tells me that leaving the range out of the map would cause it to error out a little earlier with -EINVAL just after pci_find_parent_resource(). I'd rather avoid such experiments in fear of causing regressions similar to bko#72201. This particular one remained unnoticed for 8 years. I can't possibly test all AGP drivers :/ (So much for my justification of passing this to crash independently of the iomem_resource/e820 infrastructure.) > don't worry about the user space kexec utility either. What's the problem with the userspace kexec? The bug is in reading /proc/vmcore by makedumpfile. kexec would only operate within the preallocated crashkernel area, right? Regards, -- Jiri Bohac <jbohac at suse.cz> SUSE Labs, Prague, Czechia
