On 06/02/2010 03:50 PM, Joerg Roedel wrote:
The problem with this is that it is assymetric, dev1 is treated
differently from dev[234]. It's an unintuitive API.
Its by far more unintuitive that a process needs to explicitly bind a
device to an iommu domain before it can do anything with it.
I don't really care about the iommu domain. It's a side effect. The
kernel takes care of it. I'm only worried about the API.
We have a memory map that is (often) the same for a set of devices. If
you were coding a non-kernel interface, how would you code it?
struct memory_map;
void memory_map_init(struct memory_map *mm, ...);
struct device;
void device_set_memory_map(struct device *device, struct memory_map *mm);
or
struct device;
void device_init_memory_map(struct device *dev, ...);
void device_clone_memory_map(struct device *dev, struct device *other);
I wouldn't even think of the second one personally.
If its
required anyway the binding can happen implicitly. We could allow to do
a nop 'ioctl(dev1, SHARE, dev1)' to remove the asymmetry.
It's still special. You define the memory map only for the first
device. You have to make sure dev1 doesn't go away while sharing it.
Note that this way of handling userspace iommu mappings is also a lot
simpler for most use-cases outside of KVM. If a developer wants to write
a userspace driver all it needs to do is:
dev = open();
ioctl(dev, MAP, ...);
/* use device with mappings */
close(dev);
Which is much easier than the need to create a domain explicitly.
mm = open()
ioctl(mm, MAP, ...)
dev = open();
ioctl(dev, BIND, mm);
...
close(mm);
close(dev);
so yes, more work, but once you have multiple devices which come and go
dynamically things become simpler. The map object has global lifetime
(you can even construct it if you don't assign any devices), the devices
attach to it, memory hotplug updates the memory map but doesn't touch
devices.
--
error compiling committee.c: too many arguments to function
--
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
