On 05/02/2014 12:12 PM, David Laight wrote:
From: Alexander Graf
...
+ page = pfn_to_page(pfn);
+ eaddr = (unsigned long)kmap_atomic(page);
+ eaddr |= addr & ~PAGE_MASK;
+ *instr = *(u32 *)eaddr;
+ kunmap_atomic((u32 *)eaddr);
I think I'd rather write this as
*instr = *(u32 *)(eaddr | (addr & ~PAGE));
kunmap_atomic((void*)eaddr);
to make sure we pass the unmap function the same value we got from the
map function.
Otherwise looks good to me.
Is there any mileage in keeping a virtual address page allocated (per cpu)
for this (and similar) accesses to physical memory?
Not having to search for a free VA page might speed things up (if that matters).
I like the idea, though I'm not sure how that would best fit into the
current memory mapping ecosystem.
You also probably want the page mapped uncached - no point polluting the data
cache.
Do e500 chips have a shared I/D cache somewhere? If they do, that
particular instruction would already be there, so no pollution but nice
performance.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
