device-assignment: difference between assigned_dev_iomem_map and ...map_slow

[Jan Kiszka <jan.kiszka@siemens.com>]

Hi,

latest qemu-kvm bails out on cleanup as it tries to call
cpu_register_physical_memory with a zero-sized region of an assigned
device. That made me dig into the setup/cleanup of memory mapped io
regions, trying to consolidate and fix the code.

What are the differences between normal and slow mmio regions? The
former are mapped directly to the physical device (via
qemu_ram_alloc_from_ptr + cpu_register_physical_memory), the latter have
to be dispatched in user land (thus cpu_register_io_memory +
cpu_register_physical_memory), right?

But why do we need to postpone cpu_register_io_memory to
assigned_dev_iomem_map_slow? It looks like that's effectively the only
difference between both mapping callbacks (subtracting some bugs and
dead code). Can't we set up the io region in
assigned_dev_register_regions analogously to normal regions?

BTW, the current code is leaking the slow io region on cleanup.

Comments appreciated, will translate them into a cleanup patch series.

Thanks,
Jan (who wanted to do something completely different...)

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux