Am Monday 27 April 2009 16:32:56 schrieb Michael S. Tsirkin:
> > I dont know, if that is feasible for MSI, but the transport(virtio_pci) should
> > already know the number of virtqueues, which should match the number of
> > vectors, no?
>
> I think no, the transport can find out the max number of vectors the
> device supports (pci_msix_table_size), but not how many virtqueues are
> needed by the driver.
I was not talking about the number of vectors, but the number of real exisiting virtqueues.
I just read virtio_pci again and yes,it would be a bit hard to get the number
of available virtqueues, because we need to loop over all possible vqs:
(something like)
for (i=0; i < SOMEMAX; i++) {
iowrite16(i, vp_dev->ioaddr + VIRTIO_PCI_QUEUE_SEL);
if (!ioread16(vp_dev->ioaddr + VIRTIO_PCI_QUEUE_NUM))
break;
}
return i;
which is obviously not very nice.
On the other hand, at the moment we have up to 3 virtqueues per device (network), and we have a current maximum of 16 virtqeues in qemu (VIRTIO_PCI_QUEUE_MAX in virtio.c), which would reduce the number.
> As number of virtqueues <= number of vectors,
> we could pre-allocate all vectors that host supports, but this seems
> a bit drastic as an MSI-X device could support up to 2K vectors.
>
> > In fact, the transport has to have a way of getting the number of virtqeues
> > because find_vq returns ENOENT on invalid index numbers.
> >
> > Christian
>
> So again, I think this is an upper bound supported by host. Right?
Not the upper bound, but the real available virtqueues. (With current qemu
3 for virtio-net, 2 for virtio-console etc.)
Since I use a different transport (drivers/s390/kvm/kvm_virtio.c), my motiviation is to keep the virtio interface as generic as possible. I dont really like the new interface, but I cannot give you silver bullet technical reasons - its more a gut feeling. The interface would work with lguest and s390.
Anyway. Avis suggestion to decouple MSI count and virtqueue count looks
like a promising approach.
Christian
--
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
