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. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization