> > That's pointless; cirrus for example has 8MB of mmio while a > > cpu-to-vram blit is in progress, and some random device we'll add > > tomorrow could easily introduce more. Our APIs shouldn't depend on > > properties of emulated hardware, at least as much as possible. > > One way to think of what I'm suggesting, is that if for every > cpu_register_physical_memory call for MMIO, we allocated a buffer, then > whenever map() was called on MMIO, we would return that already > allocated buffer. The overhead is fixed and honestly relatively small. > Much smaller than dma.c proposes.
I Wouldn't be surprised if some machines had a large memory mapped IO space. Most of it might not be actively used, but once you start considering 64-bit machines on 32-bit hosts these allocations would become problematic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
