On 04.06.20 17:27, David Hildenbrand wrote: > On 04.06.20 17:06, Christoph Hellwig wrote: >> On Thu, Jun 04, 2020 at 01:32:40PM +0200, David Hildenbrand wrote: >>> Just a thought: If memory hotplug is applicable as well, you might >>> either want to always assume data->enable_4GB, or handle memory hotplug >>> events from the memory notifier, when new memory gets onlined (not sure >>> how tricky that is). >> >> We probably want a highest_pfn_possible() or similar API instead of >> having drivers poking into random VM internals. > > Well, memory notifiers are a reasonable api used accross the kernel to > get notified when new memory is onlined to the buddy that could be used > for allocations. > > highest_pfn_possible() would have to default to something linked to > MAX_PHYSMEM_BITS whenever memory hotplug is configured, I am not sure > how helpful that is (IOW, you can just default to enable_4GB=true in > that case instead in most cases).
Correction: At least on x86-64 we have max_possible_pfn, which will consult the ACPI SRAT table to figure out the maximum possible PFN. (Without SRAT, max_possible_pfn will point at the end of initial boot memory and not consider hotplug memory - something that e.g., newer QEMU versions work around by creating SRAT tables if memory hotplug might be possible, even if there is no actual NUMA configuration). pci-swiotlb.c similarly relies on that to figure out if there are any !DMA addresses to handle. -- Thanks, David / dhildenb _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
