On Fri, Jun 06, 2008 at 02:28:36PM -0700, Grant Grundler wrote: > Historically the IOMMUs needed physically contiguous memory and > resizing essentially meant quiescing all DMA, moving the IO Pdir > data to the new bigger location, allocating a new bitmap and cloning > the state into that as well, and then resuming DMA operations. The > DMA quiesce requirement effectively meant a reboot. My understanding > of Vt-d is the ranges can be added range at a time and thus can be > easily resized. VT-d uses a multi-level page-table, so there would be no problem resizing. > But it will mean more complex logic in the IOMMU bitmap handling for > a domain which owns multiple bitmaps and thus a slightly higher CPU > utilization cost. At least that's my guess. I'm not working on any > IOMMU code lately... The logic seems pretty simple to me, all we need to do is keep track of how many entries are currently allocated in the bitmap vs. the size of the bitmap. Once we get to the half-way point, double the size of the bitmap. Having said that, I'm not sure it's worth it, and have no plans to implement it :-) Cheers, Muli -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
