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
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
