Michael S. Tsirkin wrote: > 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. > We can provide the round-robin mapper as a helper, so driver code doesn't need to implement any callback if they're satisfied with the default. -- 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