On Mon, May 04, 2009 at 12:21:28PM +0300, Avi Kivity wrote: > Michael S. Tsirkin wrote: >>>> So what I see is transports providing something like: >>>> >>>> struct virtio_interrupt_mapping { >>>> int virtqueue; >>>> int interrupt; >>>> }; >>>> >>>> map_vqs_to_interrupt(dev, struct virtio_interrupt_mapping *, int nvirtqueues); >>>> unmap_vqs(dev); >>>> >>> Isn't that the same thing? Please explain the flow. >>> >> >> So to map vq 0 to vector 0, vq 1 to vector 1 and vq 2 to vector 2 the driver would do: >> >> struct virtio_interrupt_mapping mapping[3] = { {0, 0}, {1, 1}, {2, 2} }; >> vec = map_vqs_to_interrupt(dev, mapping, 3); >> if (vec) { >> error handling >> } >> >> and then find_vq as usual. >> > > Yes, that works. > > Given that pci_enable_msix() can fail, we can put the retry loop in > virtio-pci, and instead of a static mapping, supply a dynamic mapping: > > static void get_vq_interrupt(..., int nr_interrupts, int vq) > { > /* reserve interrupt 0 to config changes; round-robin vqs to > interrupts */ > return 1 + (vq % (nr_interrupts - 1)); > } > > driver_init() > { > map_vqs_to_interrupt(dev, get_vq_interrupt); > } > > map_vqs_to_interrupts() would call get_vq_interrupt() for each vq, > assuming the maximum nr_interrupts, and retry with smaller nr_interrupts > on failure. Since guest drivers are going to do round-robin most of the time, I think the right thing to do is to make the API simple, along the lines proposed by Rusty, and make the guest/host ABI rich enough to support arbitrary mapping, along the lines proposed by you. We can always change the API, ABI is harder. -- MST -- 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