On 01/03/18 01:29 PM, Benjamin Herrenschmidt wrote:
Oliver can you look into this ? You sais the memory was effectively
hotplug'ed into the system when creating the struct pages. That would
mean to me that it's a) mapped (which for us is cachable, maybe x86 has
tricks to avoid that) and b) potentially used to populate userspace
pages (that will definitely be cachable). Unless there's something in
there you didn't see that prevents it.
Yes, we've been specifically prohibiting all cases where these pages get
passed to userspace. We don't want that. Although it works in limited
cases (ie x86), and we use it for some testing, there are dragons there.
- Our MMIO space is very far away from memory (high bits set in
address) which causes problem with things like vmmemmap, page_address,
virt_to_page etc... Do you have similar issues on arm64 ?
No similar issues on arm64. Any chance you could simply not map the PCI
bars that way? What's the point of that? It may simply mean ppc64 can't
be supported until either that changes or the kernel infrastructure gets
Logan, the only reason you need struct page's to begin with is
DMA API right ? Or am I missing something here ?
It's not so much the DMA map API as it is the entire kernel
infrastructure. Scatter lists (which are universally used to setup DMA
requests) require pages and bios require pages, etc, etc. In fact, this
patch set, in its current form, routes around the DMA API entirely.
Myself and others have done prototype work to migrate away from
struct pages and to use pfn_t instead but this work doesn't seem to get
very far in the community.